A.8.7 Malware Protection for MSPs: ISO 27001 Evidence and Auditable Controls

The new ransomware reality for MSPs

Ransomware increasingly treats your MSP as the quickest route into dozens of client environments at once. Attackers aim at your remote access, management platforms and shared admin accounts so that a single compromise can fan out across many tenants. That means “good enough” malware protection is no longer just an endpoint product choice; it is your ability to contain an incident before it becomes a multi‑tenant crisis and to show customers and auditors that you can do so consistently.

That shift matters because it changes what “good enough” looks like. Endpoint tools on their own are only one element in a wider control: how you configure them, how you monitor them, how you respond and how you demonstrate all of that to others. At the same time, customers, insurers and auditors are asking tougher questions about how you secure endpoints in practice, not just which product logo appears on your slide deck. Law‑enforcement threat assessments, such as Europol’s Serious and Organised Crime Threat Assessment, highlight that organised ransomware groups increasingly target service providers and intermediaries to maximise cross‑victim impact, which is exactly the position MSPs occupy.

Almost all respondents in the 2025 State of Information Security report list achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a top priority.

Strong security often depends less on new purchases and more on making your existing tools behave consistently.

Why MSPs are prime targets

Attackers focus on MSPs because compromising your access and automation gives them reach that is hard to achieve one victim at a time. Your remote monitoring and management platform, privileged service accounts and update mechanisms are attractive because they let an attacker move from one compromised host into many client estates with worrying speed. Industry ransomware trend reports repeatedly describe campaigns in which threat actors abuse MSP or RMM access to deliver payloads across many customers in a single operation, rather than attacking each organisation separately.

Most organisations in the 2025 State of Information Security survey say they have already been impacted by at least one third-party or vendor security incident in the past year.

A modern campaign often chains together several steps. It might start with stolen or phished technician credentials, then abuse remote administration, disable endpoint agents and finally push malicious payloads through your update or scripting channels. Once you picture that sequence, it is worth asking a blunt question: if one privileged endpoint in your own environment is compromised, how far could an attacker plausibly travel using the access and automation you rely on every day?

That thought experiment is not there to alarm you; it is there to highlight where your current protections really sit. If the honest answer is “further than we would like”, Annex A.8.7 is one of the levers you can use to tighten that storey in a structured, auditable way.

From instal AV to run a control

A.8.7 pushes you from we instal anti‑virus everywhere to we run a repeatable malware control that we can explain and evidence. That means defining what every managed endpoint must run, how it should behave, and how you confirm that behaviour across tenants, instead of relying on individual engineers preferences or historic product choices.

For many MSPs, endpoint security grew organically. Different engineers preferred different vendors, some clients insisted on keeping an old anti‑virus product, and baseline settings lived in tribal knowledge rather than a written standard. The unspoken assumption was that anti‑virus everywhere equalled compliance and reasonable care.

Annex A.8.7 breaks that illusion. The control expects protection against malware to be designed, implemented and supported by user awareness in a way that can be demonstrated. Summaries of the ISO 27001:2022 update note that the refreshed Annex A controls, including A.8.7, place greater emphasis on implemented and evidenced technical measures alongside user awareness, rather than simply naming a product. In practice, that means you:

Define what every managed endpoint must run.
Set clear rules for updates, scans and responses.
Gather evidence that these things actually happen.

Once you accept that shift, the conversation stops being about which vendor is best and starts being about how you standardise behaviour across all the devices and tenants you look after.

Book a demo

What ISO 27001:2022 A.8.7 actually demands of MSP services

For an MSP, A.8.7 expects you to run malware protection as a documented, monitored control that combines technology, configuration, process and user awareness, and that you can demonstrate to auditors and clients rather than just stating that you “use an EDR tool”. Commentary on the 2022 revision of ISO 27001 highlights that Annex A.8.7 is intended to drive documented, monitored malware controls supported by user awareness, rather than a simple checkbox that some form of anti‑malware is present. Although Annex A.8.7 is brief in the standard, its intent is clear: implement protection against malware, back it with appropriate user awareness so that information and other associated assets are protected, and be able to explain and show that combination in action. If you host, operate or manage endpoint security for customers, your services are therefore a major part of how they satisfy A.8.7, and the real question is not just whether you use modern tools, but whether your tools, settings and processes together deliver what the control expects.

The 2025 State of Information Security report notes that customers increasingly expect suppliers to align with formal frameworks such as ISO 27001, ISO 27701, GDPR, Cyber Essentials and SOC 2, alongside emerging AI standards.

The control in plain language

Stripping away the formal wording, A.8.7 expects you to deploy appropriate malware protection, keep it effective, monitor what it finds and support users so that malware risks stay within acceptable limits. It is as interested in how people behave and how you respond as it is in the agent installed on a device. In practical terms, the control asks you to:

Put appropriate anti‑malware or endpoint protection on relevant systems.
Keep those protections updated and securely configured.
Monitor detections and incidents and respond in a timely way.
Help users recognise and report suspicious activity.

For you, that raises immediately practical questions. Where are these expectations captured in your own policies and standards? Do your service descriptions and runbooks line up with them? When a client asks how you support their compliance, can you point to specific documents and dashboards that show A.8.7 in action, rather than just reciting tool names?

How auditors interpret A.8.7 for MSPs

Auditors usually look for a few consistent themes when assessing A.8.7 in MSP environments. They want to see that you and your clients have defined how malware protection should work, implemented it consistently, supported it with user awareness and checked regularly that it still works as intended. Broader oversight work on audits and accountability frequently highlights the same pattern: clear policies and standards, defined baselines, and evidence that controls operate as described, and many private‑sector auditors apply similar expectations when they look at security controls.

In an MSP context, that often means examining your malware or endpoint security policy, your baseline configurations for different device types, sampling endpoints to confirm agents and policies are applied, and reviewing incident records, training logs and awareness campaigns. When your services are part of a client’s ISMS, auditors will probe how responsibilities are shared: which endpoints you secure, which ones the client manages, and how you coordinate on incidents, training and exceptions.

If your answers are scattered across service catalogues, emails and engineer memories, you will find those questions stressful. If instead you treat A.8.7 as a service design problem, you can prepare a coherent storey long before an audit date appears. An ISMS platform such as ISMS.online can help you document those expectations, link them to Annex A.8.7 and keep evidence aligned with the control so you have a consistent narrative ready when someone asks, “show me”.

This overview is general information about A.8.7, not legal or certification advice. For binding decisions you should always consult the official standard and, where appropriate, qualified advisers.

ISMS.online gives you an 81% Headstart from the moment you log on

ISO 27001 made easy

We’ve done the hard work for you, giving you an 81% Headstart from the moment you log on. All you have to do is fill in the blanks.

Get started

Threat vectors A.8.7 expects you to cover across tenants

A.8.7 expects you to understand the main routes by which malware can enter and move within your own and your clients’ environments, and to put sensible, monitored controls around those routes. For an MSP, that means looking beyond “malicious files” and considering email, web, remote tools, removable media and abuse of legitimate administration features across multiple tenants.

Malware reaches your managed estates through a small number of repeatable routes that attackers use again and again. It arrives through email, browsers, documents, removable media, remote administration and even legitimate tools abused in the wrong hands. Practitioner guidance on building malware defence programmes consistently finds that most real‑world incidents arise from a relatively small set of recurring infection vectors, reinforcing the value of focusing on those routes first rather than trying to cover every hypothetical scenario at once. A.8.7 expects you to consider all relevant vectors in your environment and choose measures that reduce risk to an acceptable level, based on real‑world experience rather than theory alone.

For an MSP, those vectors span both your own infrastructure and your clients’ estates. Standardising protection therefore starts with naming the ways malware can realistically reach and move between the systems you manage, and checking how your current controls stack up against that list.

Core malware paths in MSP estates

Across many MSP environments, a handful of routes drive the majority of real‑world incidents: phishing emails and attachments, web downloads from compromised or fake sites, abuse of remote access tools and remote monitoring and management agents, infected or untrusted removable media, and misuse of existing administrative tools. Understanding how each appears in your environment gives you a practical starting point for defining your own A.8.7 baselines. Community malware‑defence material repeatedly highlights those same vectors as dominant sources of infection, which should give you confidence that focusing there first aligns with real‑world experience.

You do not have to reinvent threat intelligence to get started. A practical step is to take those routes and ask, for each one:

What do we expect to happen today if this vector is used?
How do we know that expectation is being met in live environments?
Who is responsible for fixing gaps when we find them?

If the answer for removable media is “it depends who set up the machine”, or for remote access is “we trust our technicians not to make mistakes”, that is a signal that your A.8.7 implementation is tool‑centric rather than control‑centric.

A simple table can help you structure this thinking:

Vector	What it looks like for you	Typical baseline controls
Phishing / attachments	Users on managed mail and productivity platforms	Email filtering, attachment scanning, user training
Web downloads	Browsing from managed laptops and desktops	Web filtering, DNS filtering, browser hardening
Remote access / RMM	Technicians using remote tools into client systems	Strong auth, approvals, activity monitoring
Removable media	USB devices plugged into endpoints	Port control, auto‑run disabled, scanning on insert
Admin tools misuse	Script and admin consoles used for bulk changes	Application control, logging, least‑privilege access

The aim is not perfection on day one; it is to make the implicit explicit so you can see where your current baselines do and do not match your risk.

How these vectors map to A.8.7

Under A.8.7 you should define how you protect against the important malware routes in your environment and show that those protections are applied in practice. That means you have thought about the main vectors, selected appropriate defences and can demonstrate they are in place and working. Research into risk‑based cyber‑security management supports tailoring the depth and mix of controls to the asset and organisational risk profile, rather than attempting to enforce identical “maximum” controls everywhere regardless of context.

For MSPs, that typically means documented expectations for email and web filtering, endpoint agents, safe use of removable media, secure remote administration, and monitoring, response and user awareness procedures when attacks are detected. You do not need identical measures for every client. A small local business with limited external exposure might reasonably run a simpler stack than a regulated financial institution.

What matters is that you can explain, risk‑based, why a given tenant has a particular mix of controls and that you can demonstrate those controls exist and are working. If you can do that, you are well on your way to meeting A.8.7 in a way that feels credible both in audits and in customer conversations.

Reframing A.8.7 as an MSP service design and governance problem

You get the most value from A.8.7 when you treat malware protection as a designed, governed service you deliver across customers, rather than a tick‑box in someone else’s audit. Once you view it this way, you can standardise components, clarify responsibilities and improve margins instead of fighting the same fires in slightly different ways for every tenant.

Many MSPs first meet A.8.7 through a customer’s audit question or RFP spreadsheet. It shows up as a row asking whether you “protect against malware” and which tools you use. If you only ever treat it as a checkbox, you will miss the opportunity to turn it into a differentiating, standardised service that reduces risk and improves margins.

Instead, it helps to think of A.8.7 as describing a service you provide: a malware protection service with defined components, responsibilities and evidence, delivered consistently across tenants.

Think in services, not tools

Thinking in services forces you to define how all the moving parts fit together, not just which brands you instal. Tools are part of the answer, but they are not the service you are selling or evidencing against A.8.7.

A robust malware protection service usually includes:

Clearly documented policies and standards for malware protection.
Defined endpoint baselines for each device type and risk tier.
Processes for deployment, updates and health checking.
Monitoring and alert‑handling procedures.
User awareness, training and phishing simulations.
Systems for managing exceptions and continual improvement.

Tools such as EDR platforms, remote monitoring systems and secure email gateways support these elements but do not replace them. If you sketch those components, you can then ask “where is each of these captured today?” You may find that baselines live in separate project documents, monitoring rules in your EDR console, and awareness activities in occasional emails. Bringing them together under a single service definition makes it easier to manage, explain and price what you actually do for clients.

Governance, roles and shared responsibilities

Design without governance will drift. A.8.7 sits within a broader information security management system that expects clarity about who can make changes, accept risk and sign off exceptions. Without that clarity, even good technical controls become inconsistent over time and ownership disputes appear at the worst moment.

Around two-thirds of organisations in the 2025 ISMS.online survey say the speed and volume of regulatory change are making compliance harder to sustain.

Governance for malware protection means deciding who owns the standard, who can approve deviations from it, who is responsible for monitoring execution and how decisions are recorded and reviewed. For an MSP, that might involve a security or compliance lead, operations managers, account owners and client contacts, all with well‑defined roles that are visible rather than hidden in informal agreements.

Because you are delivering services into another organisation’s ISMS, it also matters to be explicit about shared responsibilities. Which endpoints, workloads and channels are you contracted to protect? Which fall outside your scope? How are incidents involving both sides coordinated? Exceptions and risk acceptance for malware controls should be documented in your ISMS and, where relevant, reflected in the client’s Statement of Applicability so there is no ambiguity later.

For non‑security MSP owners, this structure is about more than compliance. Clear roles, baselines and evidence reduce firefighting, create repeatable work and make it easier to scale profitably. An ISMS platform such as ISMS.online can help you hold those roles, documents and decisions in one place so governance is visible and easier to monitor as the business grows.

Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.

Book your demo

Designing a standardised, risk‑tiered EDR baseline

A risk‑tiered EDR and anti‑malware baseline lets you decide, once, how much protection different tenants and assets should receive, and then apply that decision consistently. Instead of bespoke setups everywhere, you have a small set of standard levels aligned to risk and business context that you can explain to customers, staff and auditors.

Once you view A.8.7 through the lens of service design, you can move on to one of the most powerful levers you have: a standardised, risk‑tiered baseline for endpoint detection and response and anti‑malware. A shared baseline lets you answer questions such as “what does every managed workstation get, as a minimum?” or “how do we treat high‑risk endpoints differently?” without reinventing the wheel for every client.

Defining your risk tiers

Not every client or device needs the same level of protection, but every choice should be deliberate. A straightforward way to start is to create two or three risk tiers that reflect data sensitivity, regulatory pressure, external exposure and tolerance for downtime.

A practical risk‑tiering model groups clients and systems into levels such as standard, enhanced and high‑risk. Each level is then mapped to specific endpoint controls, monitoring depth and response expectations. Decisions about which tenants and asset classes sit in each tier should be based on risk assessments and business context, not just budget or convenience.

When you define these tiers, write down the criteria. For example, any tenant processing regulated financial or health data might be “enhanced” by default, while internal admin workstations with broad access to many tenants might automatically fall into the “high‑risk” bucket. Having those rules written makes it easier to defend them during audits and to explain them to customers and insurers.

Building the EDR baseline per tier

With tiers in hand, you can define a baseline for each one so you move from “we use EDR” to “these are the minimum capabilities and settings we expect for this risk level”. That clarity helps engineers, account managers and auditors all pull in the same direction.

A well‑designed EDR baseline describes minimum capabilities such as real‑time and behavioural detection, central policy control, automatic updates, isolation options, and logging and telemetry retention. It also captures configuration items such as which behaviours are blocked versus alerted, how long logs are retained and what counts as a trigger for human review or automatic isolation for each risk tier.

On top of that, the baseline should specify how EDR integrates with other parts of your stack: email and web filtering on the front end, identity and access management for privileged accounts, and ticketing and incident management systems for follow‑up. An alert that never reaches a person or a process is not a useful part of your A.8.7 storey, no matter how capable the technology behind it may be.

Balancing all of this against operational reality is important. High‑risk tenants may tolerate more aggressive blocking and higher alert volumes; lower‑risk environments might favour a lighter touch. The key is to define those differences intentionally, measure their impact and record the rationale so you can review and adjust as threats and business needs evolve.

Anti‑malware and EDR baselines by device and environment type

A.8.7 also expects you to apply malware protection appropriately to different device and environment types, not to assume that one configuration fits everything: workstations, servers, admin endpoints, remote users, virtual desktops, cloud workloads and operational technology all carry different risks and constraints, so your baselines need to reflect those differences. Risk tiers answer “how much” protection; device and environment types answer “where and how” it is applied, and an effective A.8.7 implementation has to recognise those realities. A credible A.8.7 approach for an MSP therefore sets out practical baselines for each category, along with clear handling of exceptions when you cannot apply your preferred controls.

In many MSP environments, a small number of endpoint categories dominate: user workstations and laptops, servers and privileged admin endpoints used to manage many environments. Each category has a different role and risk profile, so each deserves a tailored but standard baseline.

Each endpoint category should have a documented baseline describing:

Which anti‑malware or EDR agent must be present.
Which core protection features must be enabled.
How often signatures and engines update.
How often scans run and what they cover.
Which behaviours are blocked or only alerted.
How logs are collected and retained.
What additional controls apply for that category.

For workstations, that might include web filtering and attachment controls. For servers, it could involve tighter change control and more conservative automated responses. For admin endpoints, you might mandate stronger hardening, application allow‑listing and enhanced logging so you can reconstruct activity if anything goes wrong.

Remote and hybrid workers deserve special attention. Devices that spend long periods off the corporate network or outside your usual remote management reach can easily fall out of compliance. Studies of endpoint misconfiguration and configuration drift note that off‑network or unmanaged devices are particularly prone to missing updates or deviating from expected baselines, which is why they deserve explicit attention in your standards.

Handling remote, cloud, OT and legacy constraints

Not every environment allows you to run the same agent or configuration. Line‑of‑business applications may conflict with certain scans, some operating systems may not be supported by your chosen tools, and operational technology often has strict performance and change‑management constraints that limit what you can instal.

These realities do not let you ignore A.8.7; they simply move you into the world of compensating controls and documented exceptions. Where you cannot run a full agent, you might instead enforce network isolation, stricter access control, additional monitoring at network boundaries, or more frequent backups and restore tests. Where you need to exclude directories or processes from scanning, you should treat those exclusions as risk decisions: approved by someone with authority, justified, recorded and reviewed regularly.

In all of these cases, transparency is critical. You should know which systems deviate from your standard baseline, why, what alternative protections apply and when you will review whether those exceptions are still necessary. That record, held in your ISMS and reflected in your clients’ Statements of Applicability where relevant, becomes a crucial part of how you show that your A.8.7 implementation is risk‑based and deliberate rather than relaxed or accidental.

ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.

Book your demo

Documenting, monitoring and evidencing A.8.7 for audits and clients

To satisfy A.8.7, you need to be able to show what you expect to happen, that it actually happens and that you refine it over time. Documentation, monitoring and evidence turn good intentions into a storey you can stand behind with auditors, customers and non‑security leaders who need to see that their business risk is under control.

Even a well‑designed baseline does not satisfy A.8.7 on its own. The control expects protection to be implemented, monitored and improved over time. Clients and auditors want to see that storey in a way they can follow, and MSP owners want to see that it reduces firefighting rather than adding to it.

If you treat evidence as an afterthought, you will find yourself scrambling whenever a questionnaire or audit appears. If you build it into your workflows, you can answer most questions with reports you already use to run the business and show progress over time.

Your A.8.7 chain of evidence

A strong evidence chain for malware protection connects your policies, baselines, deployment records, detections and review activity into a single, coherent picture. The aim is to make it easy to trace from a written expectation to real‑world execution and back again.

In practice, that usually means having:

Documented policies and standards for malware protection.
Baseline configurations per tier, device and environment type.
Records of deployment, agent health and coverage.
Logs of detections, responses and incident tickets.
Notes or minutes from reviews and improvement actions.

In practical terms, you might store your malware policy and endpoint standards in your ISMS, export regular coverage and compliance reports from your EDR and remote monitoring tools, link incident tickets back to the controls they relate to, and capture a handful of key decisions from each review meeting. When an auditor asks “show me how you protect against malware”, you can then produce a coherent pack rather than a folder full of unconnected screenshots. An ISMS platform such as ISMS.online can help you hold those artefacts together so the chain of evidence is visible and easy to maintain.

KPIs, reviews and client reporting

Metrics and reporting are where A.8.7 meets continual improvement. They move you beyond point‑in‑time compliance and into a more honest conversation about how well your controls work, where they need attention and how your service quality affects business results. Specialist analysis on using metrics to manage cyber risk frequently recommends coverage and control‑health indicators as key measures of operational security performance, which aligns naturally with A.8.7.

In the 2025 ISMS.online State of Information Security survey, about 41% of organisations named managing third-party risk and tracking supplier compliance as a top challenge.

Useful indicators include:

Percentage of in‑scope endpoints with an active, healthy agent.
Time taken to update engines and signatures across estates.
Rate of malware detections per tenant or segment.
Time from alert to containment or remediation.
Number and age of outstanding exceptions.
Number of malware‑related incidents or near‑misses.

Regularly reviewing those numbers with the right people helps you spot where your baseline needs refinement. For clients, digestible reporting builds trust. Many will not want a deep technical dump, but they will appreciate clear statements such as “all in‑scope endpoints had active protection at last check”, “three malware incidents were detected and contained within agreed times”, and “one long‑standing scanning exclusion was removed after application updates”.

When those summaries are backed by more detailed evidence available on request, both sides can feel more confident about their shared risk. You also make it much easier to respond consistently when questionnaires, renewals and due‑diligence requests arrive, and you can show MSP leaders that disciplined A.8.7 management reduces unplanned work rather than just adding overhead.

Book a Demo With ISMS.online Today

ISMS.online helps you turn your A.8.7 obligations into one coherent storey you can share with auditors, customers and internal stakeholders. By connecting risks, policies, baselines, exceptions and evidence in one place, it makes it easier to demonstrate your control of malware risk and to show how your MSP supports each client’s wider information security management system.

See your A.8.7 storey in one place

With an ISMS platform such as ISMS.online, you can model your malware protection policies and standards, link them directly to Annex A.8.7, capture your baseline configurations for different tiers and device types, and associate relevant evidence such as reports, tickets and review notes. That makes it much easier to show how your managed services support clients’ certifications and your own internal assurance needs without assembling material from scratch before every audit.

For MSP leaders, that central view also reveals duplication and gaps. You can see where different clients are still running legacy approaches, where exclusions are piling up, and where your baselines are working well. That insight supports decisions about where to invest effort next, how to improve margins by standardising services and how to present your security maturity in bids and renewals.

Prove value quickly with a focused pilot

Moving to a more structured approach does not have to mean a large, disruptive project. A pragmatic way to start is to pick one or two representative clients and use a platform such as ISMS.online to model their A.8.7 implementation end‑to‑end, from risks and policies through to baselines and evidence.

You can then compare the effort of preparing for an audit or answering a client questionnaire using your current, ad hoc method versus pulling the same answers from a single, organised environment. Seeing how much faster and clearer audit preparation becomes in the pilot will give you a tangible case for extending that approach across your wider client base and control set.

Ultimately, A.8.7 is about more than ticking a clause in a standard. It is about showing that you can prevent, detect and contain malware in a way that protects your clients and your MSPs reputation. A well‑designed EDR and anti‑malware baseline, backed by clear documentation and an integrated ISMS platform such as ISMS.online, gives you a way to prove that storey every day, not just when an auditor calls. If you want to see how this could look in your environment, our team can walk you through a short demonstration and help you decide whether ISMS.online fits the way you already work.

Book a demo

Frequently Asked Questions

How does ISO 27001:2022 A.8.7 actually raise the bar for malware protection in an MSP?

ISO 27001:2022 A.8.7 raises the bar from “we’ve got AV everywhere” to a designed, repeatable malware control you can prove works across all managed environments. For an MSP, that means you can show how you identify malware risk, set standards, run the service, and improve it over time for any representative client.

What does “good enough” look like under A.8.7 for an MSP?

Under A.8.7, “good enough” means you can walk a sceptical auditor or enterprise CISO through a joined‑up, sensible storey:

You understand the risk:

You’ve thought about how malware could realistically hurt your customers and your own operations – from ransomware on remote laptops to a worm on shared servers – and you record those risks in your ISMS.

You’ve turned that risk into policy and scope:

You keep a short, approved malware / endpoint security policy that:

Explains the purpose of the control in business language.
Defines which tenants, locations, systems and device types are in scope.
References Annex A.8.7 so the mapping is explicit.
Points to supporting controls like A.8.8 (vulnerability management) and A.5.24–A.5.28 (incident handling).

You have a standard baseline, not “whatever the engineer set up”:

You can show written, version‑controlled baselines (standard / enhanced / high‑risk) for different device classes that define:

Minimum capabilities (EDR/AV, real‑time protection, behaviour monitoring, updates).
Scan schedules, log retention and alert thresholds.
Stricter settings for admin endpoints, shared machines and exposed systems.

You operate the service like a service:

Behind the agent you run:

Runbooks for triage, isolation, clean‑up and return‑to‑service.
Clear ownership for tuning policies and managing exclusions.
Ticket trails and metrics that show what actually happens when alerts fire.
Regular management reviews that look at coverage, incidents, exceptions and drift.

You train the people who can make or break the control:

Your own staff understand safe administration, remote access and use of privileged tools. Where your contracts say you will influence end users, you provide clear, simple guidance on email attachments, macros and removable media instead of burying them in policy PDFs.

If you can pull those threads together quickly – with policies, standards, risk decisions and evidence living in a single information security management system – A.8.7 becomes less of a trap question and more of an opportunity to showcase how mature your managed security really is. ISMS.online is designed to give you that single place to hold the storey and keep it audit‑ready.

How can an MSP turn A.8.7 into a standard EDR / anti‑malware service that scales across tenants?

You make A.8.7 scalable by treating malware protection as a repeatable product with a documented baseline, not a fresh design for every new logo. The baseline defines what “good” looks like once; risk tiers and exceptions let you flex it sensibly from client to client.

What belongs in a reusable malware baseline for MSPs?

A solid baseline usually has four building blocks you can reuse everywhere and justify quickly.

1. A clear minimum for each device class

You define what every in‑scope device must have at a minimum:

User endpoints (laptops, desktops, tablets where supported):
Centrally managed EDR or anti‑malware agent.
Real‑time protection and behavioural analysis.
Automatic signature / engine updates, with sensible fall‑back.
Web / URL filtering for common delivery paths.
Local isolation capability for suspected compromise.

Servers and critical systems:
Comparable protection, tuned to avoid business disruption.
Extra logging and alerting for unusual activity.
Tighter change control around policy changes.

Admin and jump hosts:
Stricter profiles with allow‑listing, enhanced logging and lower tolerance for exceptions.
Multi‑factor authentication and restricted use.

Being able to show “here’s the minimum every device gets by type” gives customers and auditors immediate confidence that you are not improvising per engineer.

2. Standard profiles instead of console folklore

You capture once, in writing, how your profiles behave:

What you block immediately versus raise as an alert.
When full and quick scans run and who reviews failures.
How long logs are retained and where they live.
Which events must always open a ticket (for example, ransomware‑style behaviour, repeated blocked scripts).
Which groups of endpoints sit in stricter profiles, and why.

These profiles should be version‑controlled inside your ISMS, with change history and approvals, so future audits are about showing today’s standard, not reconstructing last year’s best guesses.

3. Risk‑based tiers rather than brand‑based treatment

Instead of deciding strictness based on logo or contract value, you map tenants and devices to a simple risk tier model:

Tier	What drives it	Typical examples
Standard	Low / normal business impact	Internal office users in non‑regulated organisations
Enhanced	Higher financial or operational impact	Finance teams, shared kiosks, on‑site engineering PCs
High‑risk	Regulatory, privileged or internet‑exposed workloads	Healthcare or financial tenants, admin endpoints

The mapping lives in your asset and risk registers, so when someone asks “why is this environment locked down more than that one?” you can point at clear criteria, not personality or negotiation history.

4. A controlled, visible exception process

Real life always throws curveballs – legacy applications, performance issues, integration quirks. A.8.7 does not ban exceptions; it expects them to be managed:

Every deviation from the baseline is logged in an exception register.
Each record shows the reason, risk, compensating controls and approval.
Exceptions have an owner and a review date.
You can show how many were closed or tightened in the last period.

When your baseline, tiers and exceptions all live in ISMS.online with clear ownership, three good things happen at once:

Engineers no longer have to remember “tribal settings” per tenant.
Commercial teams can describe the service consistently in proposals and renewals.
A.8.7 conversations with auditors or customers shrink to walking through the baseline, the tier model and a couple of exception examples.

If you want that baseline to feel like part of a joined‑up ISMS rather than scattered files, building it and maintaining it in ISMS.online gives you structure and reusability from day one.

What technical and operational controls does an MSP really need to feel safe signing off A.8.7?

You want to be able to look at your service catalogue and say, with a straight face, that every device in scope is meaningfully protected and that alerts reliably turn into action. That confidence depends on both the technology you deploy and the way your team runs it.

Which technical controls should be non‑negotiable?

A realistic A.8.7‑aligned endpoint service often includes:

Coverage and deployment discipline:
Enforcement that all in‑scope endpoints – including remote workers and new devices – receive the agent automatically.
Health checks for missing or unhealthy agents, with alerting at tenant and portfolio level.
Integration with your RMM or provisioning tools to minimise onboarding gaps.

Protection and detection breadth:
Always‑on scanning of files, processes and scripts.
Behavioural detection for ransomware, script misuse and unusual child processes.
Automatic updates with guard rails on manual overrides.
Isolation or kill‑switch support so engineers can contain an incident within minutes, not hours.

Supporting controls upstream and downstream:
Email and web filtering to block common malware payloads.
Patch and configuration management to reduce exposure.
Tested backup and restore so you can recover confidently if compromise gets past endpoint defences.

Framing your control as this whole stack – not just the agent – makes it easier to explain to customers how you manage malware risk along multiple paths, not just at the last hop.

What operational evidence reassures auditors and enterprise buyers?

Most reviewers are less interested in the logo on the agent and more in whether your operation behaves consistently when it matters:

Documented playbooks:
Clear steps for triaging alerts by severity and context.
Defined actions for suspected compromise: isolate, investigate, clean, validate.
Criteria for when and how to perform forensic preservation.
Points where you inform or escalate to customer contacts.

Service levels and accountability:
Target response times for high‑priority alerts.
Named owners for baseline tuning, exclusion lists and coverage metrics.
On‑call arrangements for out‑of‑hours events, if contracts require it.

Evidence that the process runs as designed:
Tickets traced from detection through to resolution, with timestamps and outcomes.
Regular summaries showing mean time to review, contain and close incidents.
Notes from reviews where patterns in detections or false positives led to changes.

If those artefacts, metrics and decisions are linked to your A.8.7 policy and baselines inside ISMS.online, you can move from “trust us, we’re on top of it” to a simple walkthrough of how the control really works. That shift tends to land well with both auditors and larger customers who are mapping your controls back to ISO 27001 and related frameworks such as NIST CSF or SOC 2.

How can an MSP document, monitor and report A.8.7 so audits feel like a normal month, not a special project?

A.8.7 audits feel routine when your documentation, dashboards and records mirror how you already run the service, rather than forcing you into a parallel universe. The aim is a small, tidy set of artefacts that match day‑to‑day practice.

Which documents are worth keeping in tight shape?

You do not need dozens of policies; you need a few that are current, connected and easy to find:

Malware / endpoint security policy:
States purpose, scope, responsibilities and links to Annex A.8.7 (and related controls).
References your risk assessment method and baseline standards.
Lives in your ISMS with clear versioning and approvals.

Baseline and profile standards:
Describe your risk tiers, device classes and standard configurations.
Note any sector‑specific add‑ons (for example, healthcare, finance).
Are updated deliberately, not by silent tweaks in a console.

Operational procedures:
Onboarding: how new tenants and assets are brought into the service.
Monitoring: how consoles and feeds are checked, and by whom.
Incident response: the path from alert to containment, recovery and closure.
Exception management: how deviations are proposed, approved, recorded and reviewed.

Exception and deviation registers:
Track where reality differs from your baseline and why.
Show owners, compensating controls and dates for review.

Holding these elements together in ISMS.online means you can generate an audit pack quickly and your internal teams are always working from the same reference set.

What should you monitor, and how do you present it without drowning people in data?

You can usually answer most A.8.7 questions with a handful of regular metrics:

Coverage and health indicators:
% of in‑scope devices with a healthy, current agent and right policy per tenant.
Number of devices missing from coverage, with reasons (new, retired, exception).
Trend lines over time, showing whether coverage is stable, improving or slipping.

Detection and response indicators:
Number and severity of malware detections per tenant and per tier.
Average and worst‑case time to review and contain critical events.
Cases where containment relied on backup / recovery, and the outcomes.

Exception and drift indicators:
Total number of active exclusions and their average age.
Count of exceptions added and removed per period.
Observed drift between intended and actual configurations across representative tenants.

These can be summarised for audits and customer reviews in a short, human‑readable way, for example:

In the last quarter, we maintained active protection on 98.7% of in‑scope endpoints across your estate. We investigated 11 malware‑related alerts, contained three confirmed incidents inside your agreed response times, and closed five outdated exclusions that were no longer needed after application changes.

When your ISMS, your endpoint tools and your reporting line up like this – something ISMS.online is built to support – audits start to look like a structured tour of your normal telemetry rather than a scramble for screenshots.

What weaknesses around A.8.7 do auditors and customers usually find in MSPs – and how do you stay ahead?

Most uncomfortable findings cluster where your marketing promise, ticket history and formal standards don’t match. Recognising the common failure modes lets you design your A.8.7 control so that external checks confirm what you already know, instead of exposing gaps.

Where do MSPs most often stumble on A.8.7?

Typical patterns include:

Inconsistent or incomplete coverage:
Remote and BYOD devices that never receive the agent.
New tenants added without being mapped to a risk tier or baseline profile.
Critical systems left on default or legacy settings for too long.

Unwritten baselines and ad‑hoc tuning:
Engineers “roughly know” what to configure, but there is no agreed written standard.
Settings vary significantly between tenants with similar risk profiles.
No record of why stricter or looser settings were chosen.

Unmanaged exceptions and silent policy breaks:
Large exclusions added during troubleshooting and never revisited.
Scanning disabled to fix performance issues with no compensating controls.
Arguments about who owns the risk when these are discovered.

Thin, scattered evidence:
Logs and tickets stored in several unconnected systems.
Difficulty proving what happened during an incident beyond a few chat messages.
No easy way to show improvement over time.

These are precisely the weaknesses that make larger buyers nervous, especially when they compare you against ISO 27001 Annex A or their internal policies.

How does a more disciplined ISMS‑centred approach change the picture?

You do not need to become a giant enterprise to avoid these traps. A few disciplined habits, anchored in an ISMS, go a long way:

Apply your tiered baseline by default to every new tenant and asset, through your onboarding templates.
Run a single, simple exception workflow where all deviations are logged, reviewed on a schedule and linked to risk decisions.
Make coverage and exception reports a regular part of internal service reviews and customer conversations, not just audit season.
Capture lessons learned from incidents and false positives as updates to baselines, runbooks and training material.

When you manage all of this through ISMS.online – where policies, risks, controls, exceptions and evidence are joined up – you can answer A.8.7 questions calmly:

Here is how we designed the control.
Here is how we operate and measure it.
Here is how we improve it over time.

That clarity tends to move the discussion away from “why did this go wrong?” and towards “how do we extend this strength to other areas of your service?”

How can an MSP choose and defend EDR / anti‑malware tools for A.8.7 without getting stuck in vendor arguments?

Annex A.8.7 does not care which vendor you use; it cares that your malware protection is appropriate for the risk, applied consistently and shown to be effective. Your job is to show that your tool choices support the control design you have committed to – not the other way round.

What criteria should guide tool selection for A.8.7?

A practical way to decide is to start from your baseline and operational constraints, then ask of each product:

Does it support your baseline, or force compromises?:
Can you configure the real‑time, behavioural and isolation capabilities your tiers require?
Can you implement stricter profiles for high‑risk devices without complex workarounds?
Does it provide the logging you need to evidence detection, containment and recovery?

Is it genuinely multi‑tenant‑friendly?:
Can you manage many tenants from one place without endless policy duplication?
Can you enforce global standards while still allowing controlled per‑tenant variation?
Are there clear role‑based access controls so staff only see what they need?

Does it fit your existing service stack?:
Does it integrate with your ticketing, SIEM and RMM, so alerts naturally become actions?
Can you align identity, email and backup tooling with endpoint response?
Does it support the automation level your team can realistically manage?

Is the operational burden acceptable?:
How much tuning is needed to reach an acceptable signal‑to‑noise ratio?
How easily can your engineers gain and maintain competence?
What happens when there is a major upgrade or policy model change?

Framing selection in these terms helps you keep conversations with customers and auditors focused on suitability and effectiveness, not vendor marketing claims.

Once you have standardised on one or two platforms, you should be able to answer three simple questions with evidence:

Appropriateness

A short rationale in your ISMS explaining why the tool is a good fit for your customer base and risk profile.
A mapping that shows how key features support your malware policy and A.8.7 baseline.

Deployment and behaviour

Coverage and health dashboards at tenant and portfolio level.
Records of configuration reviews and change approvals.
Sample incident records that show detection, containment and clean‑up performed through the tool.

Adaptability over time

A lightweight process for re‑evaluating the toolset when new threats, regulations or customer requirements arise.
Examples of changes you have already made, such as tightening controls after a ransomware campaign in your sector.

By managing this narrative through ISMS.online – linking risks, controls, tool choices, incidents and reviews – you can move A.8.7 conversations away from “which product do you use?” toward “here is how we keep malware risk under control for organisations like yours.” That is the kind of answer that reassures compliance teams, security leaders and boards that your MSP is not just installing software, but running a thought‑through, evidence‑backed control.

A.8.7 Protection Against Malware – MSP Edr & Anti-Malware Baselines