# Malware Protection Standard: [Organization name]

> Defines the layered technical and organizational controls that prevent,
> detect and respond to malware (including ransomware, information
> stealers, malicious macros and scripts) across endpoints, servers, cloud
> workloads, e-mail and web traffic. Supports ISO/IEC 27001:2022 + Amd
> 1:2024 Annex A control A.8.7 (protection against malware), with links to
> A.6.3, A.7.10, A.8.1, A.8.8, A.8.13, A.8.16, A.8.19 and A.8.23, and the
> guidance in ISO/IEC 27002:2022.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Use it when you select or review anti-malware tooling, after a malware
  incident, or when preparing the SoA justification for A.8.7.
- Fill first: the layer table in section 4 (which tools cover which
  assets) and the coverage targets in section 10.
- Main pitfall: treating "antivirus installed" as the control. ISO/IEC
  27002:2022 guidance for A.8.7 makes clear that tools alone are not
  enough: trained people, tight access rights and controlled changes do
  much of the work. An auditor will ask
  how you know every asset is covered, how alerts are handled and what
  happened to the last detection.
- Related templates: `isms/endpoint-device-byod-policy`,
  `isms/secure-configuration-baseline`, `isms/security-monitoring-procedure`,
  `security/soc-playbook`, `compliance/incident-response-plan`,
  `isms/backup-policy`, `security/security-awareness-program`,
  `isms/phishing-simulation-plan`, `security/vulnerability-management-policy`.
-->

## Document control

<!-- Guidance: Treat changes to coverage scope, response times or the allow-listing approach as major versions. Tool or product changes alone can be minor if the requirements stay the same. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-059 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@security-operations-lead] |
| Approvers/reviewers | [@ciso], [@isms-manager], [@head-of-it] |
| Last updated | YYYY-MM-DD |
| Effective from | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.8.7, cited only); ISO/IEC 27002:2022 |
| Next scheduled review | YYYY-MM-DD (at least annually and after any malware incident rated High or Critical) |
| Parent policy | [Information security policy DOC-ISMS-001] |
| Related standards | [Endpoint and BYOD policy DOC-ISMS-058], [Secure configuration baseline DOC-ISMS-060], [Security monitoring procedure DOC-ISMS-064] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Standard owner | [@security-operations-lead] | [Prepared] | YYYY-MM-DD |
| ISMS manager | [@isms-manager] | [Reviewed] | YYYY-MM-DD |
| CISO or top management delegate | [@ciso] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [@owner] | First issue |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

- [1. Purpose and scope](#1-purpose-and-scope)
- [2. Roles and responsibilities](#2-roles-and-responsibilities)
- [3. Threat picture](#3-threat-picture)
- [4. Layered control model](#4-layered-control-model)
- [5. Endpoint and server protection requirements](#5-endpoint-and-server-protection-requirements)
- [6. E-mail, web and file controls](#6-e-mail-web-and-file-controls)
- [7. Application allow-listing, macros and scripts](#7-application-allow-listing-macros-and-scripts)
- [8. Detection and response](#8-detection-and-response)
- [9. User awareness](#9-user-awareness)
- [10. Coverage, metrics and testing](#10-coverage-metrics-and-testing)
- [11. Exceptions](#11-exceptions)
- [12. Size tiers](#12-size-tiers)
- [13. Records and evidence](#13-records-and-evidence)
- [14. References](#14-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and scope

<!-- Guidance: Name every asset class and say which layer covers it. Assets that cannot run an agent (appliances, OT, legacy) still need a stated protection, usually network isolation and monitoring. -->

This standard sets minimum requirements so that malware is blocked
before execution where possible, detected quickly where not, and
contained before it spreads or encrypts data. It applies to:

| Asset class | In scope | Primary protection |
|---|---|---|
| User endpoints (categories C1 and C2 in DOC-ISMS-058) | Yes | EDR agent, application control, hardened baseline |
| BYOD mobile (category C3) | Yes | Managed app protection, jailbreak and root detection |
| Servers (virtual and physical) | Yes | Server EDR or workload protection agent |
| Cloud workloads and containers | Yes | Workload protection, image scanning in the build pipeline |
| E-mail | Yes | Secure e-mail gateway or suite-native filtering |
| Web traffic | Yes | DNS and web filtering (A.8.23) |
| File storage and collaboration | Yes | On-upload scanning in the storage or suite service |
| Removable media | Yes | Blocked by default, scanning on approved exception (A.7.10) |
| OT and appliances that cannot run agents | [Yes / Not in scope] | Network segregation, allow-listing on HMI where supported, monitoring |

## 2. Roles and responsibilities

<!-- Guidance: Detection without an owner for triage is a common finding. Name who watches the console outside office hours, even if it is a managed service. -->

| Role | Responsibilities |
|---|---|
| Standard owner [@security-operations-lead] | Maintains this standard, the tool configuration and the coverage report |
| Security operations or managed detection service | Monitors alerts, triages and contains detections within the times in section 8 |
| IT operations [@head-of-it] | Deploys agents with every new device and server, keeps agents and signatures current |
| Cloud and platform engineering | Applies workload protection and image scanning in pipelines |
| ISMS manager [@isms-manager] | Tracks metrics, exceptions and evidence, reports to the steering committee |
| Awareness lead | Runs malware and phishing awareness under the awareness programme |
| All users | Do not disable protection, report suspicious messages and files, follow section 9 |

## 3. Threat picture

<!-- Guidance: Keep this short and update it from threat intelligence (A.5.7). It justifies why each layer exists. Reference techniques by MITRE ATT&CK technique ID if your SOC uses ATT&CK. -->

| Delivery path | Typical malware | Main layers that stop it |
|---|---|---|
| Phishing e-mail with attachment or link | Information stealers, loaders, ransomware precursors | E-mail filtering, sandboxing, macro controls, EDR, awareness |
| Malicious or compromised website, malvertising | Drive-by downloads, fake installers | Web filtering, browser hardening, application control |
| Exploited unpatched software | Remote access trojans, ransomware | Patching (A.8.8), EDR behaviour detection, segmentation |
| Stolen credentials into remote access | Hands-on-keyboard ransomware | MFA, privileged access controls, EDR, monitoring |
| Removable media | Worms, OT-targeting malware | Media blocking, scanning kiosks |
| Software supply chain | Trojanised packages and updates | Dependency scanning, signed artefacts, application control |
| Fake productivity or AI tools | Stealers, adware | Software catalogue, allow-listing, awareness |

Update this table at each annual review using the threat intelligence
procedure (DOC-ISMS-045).

## 4. Layered control model

<!-- Guidance: One table that shows defence in depth. Each layer row needs a named tool category, owner and coverage target, so gaps are visible. -->

```mermaid
flowchart LR
  A["Delivery: e-mail, web, media, supply chain"] --> B["Layer 1: e-mail and web filtering"]
  B --> C["Layer 2: hardened baseline and patching"]
  C --> D["Layer 3: application control, macro and script limits"]
  D --> E["Layer 4: EDR prevention and detection"]
  E --> F["Layer 5: monitoring, response and containment"]
  F --> G["Layer 6: tested offline or immutable backups"]
```

| Layer ID | Layer | Tool category | Owner | Coverage target *(Example)* |
|---|---|---|---|---|
| MAL-CTL-001 *(Example)* | E-mail filtering and attachment sandboxing | Suite-native protection or secure e-mail gateway | [@head-of-it] | 100% of inbound mail |
| MAL-CTL-002 *(Example)* | DNS and web filtering | Protective DNS, secure web gateway or EDR web module | [@head-of-it] | 100% of managed devices, on and off network |
| MAL-CTL-003 *(Example)* | Hardened baseline and patching | MDM, configuration management | [@head-of-it] | Per DOC-ISMS-060 and DOC-ISMS-058 section 6 |
| MAL-CTL-004 *(Example)* | Application control | OS-native allow-listing or EDR application control | [@secops] | All C1 devices, all servers |
| MAL-CTL-005 *(Example)* | Macro and script controls | Suite policy and OS script policies | [@head-of-it] | All managed devices |
| MAL-CTL-006 *(Example)* | Endpoint and workload detection and response | EDR or workload protection platform | [@secops] | 100% of endpoints and servers |
| MAL-CTL-007 *(Example)* | Monitoring and response | SIEM or EDR console, managed detection service | [@secops] | 24/7 for High and Critical alerts |
| MAL-CTL-008 *(Example)* | Recovery | Immutable or offline backups (DOC-ISMS-061) | [@head-of-it] | All Tier 1 systems |

## 5. Endpoint and server protection requirements

<!-- Guidance: These are the settings an auditor samples. Each should be visible in the EDR console. Tamper protection is the single most important setting after coverage. -->

1. Every managed endpoint and server runs the approved EDR or workload
   protection agent before it connects to production or business
   systems.
2. Tamper protection is on. Users and local administrators cannot stop,
   uninstall or reconfigure the agent. Uninstall requires a one-time
   token issued by security operations and logged.
3. Real-time protection, behaviour monitoring, cloud-delivered protection
   and ransomware protection (for example controlled folder access or
   rollback where the product supports it) are on.
4. Agent and detection content updates are automatic. A device whose
   agent has not reported for [7] days appears on the coverage exception
   list and is investigated.
5. Prevention mode, not audit-only, is used for known-bad files and
   high-confidence behaviours. Audit mode is allowed only during a
   documented tuning period of no more than [30] days.
6. Exclusions (paths, processes, hashes) are approved by security
   operations, recorded with a reason and reviewed [quarterly]. Broad
   exclusions such as whole drives or user-writable folders are not
   permitted.
7. Isolation from the network can be triggered remotely by security
   operations for any endpoint or server.
8. Linux and container hosts use workload protection that supports the
   distributions in the secure configuration baseline (DOC-ISMS-060).
   Container images are scanned in the pipeline and at runtime.
9. Full scans of servers run [weekly], timed to avoid business impact.

## 6. E-mail, web and file controls

<!-- Guidance: Most malware still arrives by e-mail or web. Describe settings conceptually, because product names and console labels change. The SaaS baseline holds the suite-specific settings. -->

| Area | Requirement |
|---|---|
| Inbound attachments | Scan all attachments, detonate unknown executables and documents in a sandbox, block executable and script file types listed in [blocked type list] |
| Links | Rewrite or check links at time of click, block known malicious domains |
| Sender authentication | Enforce SPF, DKIM and DMARC checks on inbound mail, mark external senders (see DOC-ISMS-075) |
| Encrypted archives | Quarantine password-protected archives from external senders unless the recipient requests release through the service desk |
| Web filtering | Block malware, phishing, newly registered and uncategorised domains on managed devices, on and off network |
| Downloads | Block executable downloads from uncategorised sites, scan all other downloads |
| File storage | Scan files on upload to cloud storage and collaboration sites, quarantine detections |
| Removable media | Block mass storage on C1 devices by default. Approved exceptions require scanning at a dedicated kiosk |

## 7. Application allow-listing, macros and scripts

<!-- Guidance: Allow-listing is the strongest preventive layer and the hardest to run. Start on servers and fixed-function devices, then extend to staff devices in rings. Record the mode (enforce or audit) per group. -->

| Control | Requirement | Mode per group *(Example)* |
|---|---|---|
| Application allow-listing | Only signed software from approved publishers and the software catalogue runs | Servers: enforce. Finance and HR laptops: enforce. Engineering laptops: audit with weekly review |
| User-writable locations | Block execution from downloads, temp and user profile folders | All C1 devices: enforce |
| Office macros | Block macros in files from the internet. Allow only signed macros from trusted publishers where a business need exists | All users |
| Scripting engines | Constrained or logged script execution, block script hosts for standard users where not needed | All C1 devices |
| Living-off-the-land tools | Block or alert on misuse of built-in admin tools by non-admins | EDR rule set |
| Browser extensions | Allow-list only | All managed browsers |

Exceptions to allow-listing for developer tools follow section 11 and
are scoped to named groups and paths.

## 8. Detection and response

<!-- Guidance: State response times you can meet with your staffing. If you rely on a managed detection service, write their contracted times here and keep the contract as evidence. -->

```mermaid
flowchart TD
  A["Detection: EDR, e-mail, web or user report"] --> B["Triage: true or false positive?"]
  B -->|False positive| C["Close, tune rule, record reason"]
  B -->|True positive| D{"Contained automatically?"}
  D -->|Yes, blocked before execution| E["Check scope, close as event"]
  D -->|No or executed| F["Isolate host, revoke sessions"]
  F --> G["Raise incident per DOC-ISMS-020"]
  G --> H["Eradicate, rebuild or restore"]
  H --> I["Lessons learned, update controls"]
```

| Alert severity | Example | Triage time *(Example)* | Containment time *(Example)* |
|---|---|---|---|
| Critical | Ransomware behaviour, credential dumping on a server | 15 minutes, 24/7 | 1 hour |
| High | Malware executed on an endpoint, malicious macro run | 1 hour, 24/7 | 4 hours |
| Medium | Malware blocked on execution, suspicious script | 1 business day | Not applicable if blocked |
| Low | Adware, potentially unwanted application | 3 business days | Removal at next maintenance |

Rules:

1. Security operations follow the malware playbook in
   `security/soc-playbook` and log every true positive in the incident
   register (DOC-ISMS-021).
2. Executed malware on a host with access to restricted data is always
   an incident under the incident response plan (DOC-ISMS-020).
3. Compromised hosts are rebuilt from a known-good image rather than
   cleaned, unless forensic and business reasons justify cleaning.
4. Evidence is preserved before rebuild when the incident may lead to
   legal action (`security/forensic-evidence-record`).
5. Indicators from confirmed incidents are added to blocking rules and
   shared with sector groups where agreed (DOC-ISMS-069).
6. After a High or Critical malware incident, a post-incident review
   (DOC-ISMS-022) checks which layer failed and updates this standard.

## 9. User awareness

<!-- Guidance: A.8.7 relies on people as one layer. Tie the awareness content to the delivery paths in section 3, and measure reporting, not just clicks. -->

1. All staff complete malware and phishing awareness at onboarding and
   [annually] through the awareness programme
   (`security/security-awareness-program`).
2. Phishing simulations follow the phishing simulation plan
   (DOC-ISMS-074).
3. Staff report suspicious messages with the [report button / address].
   Reports are acknowledged and the reporter told the outcome where
   practical.
4. Staff never disable security tools, never run software from unknown
   sources and never plug in found removable media.
5. Short notices are sent when a relevant campaign is active, based on
   threat intelligence.

## 10. Coverage, metrics and testing

<!-- Guidance: Coverage is the first thing to prove: compare the EDR device list with the asset inventory and MDM each month. A gap of a few devices is normal, an unexplained gap is a finding. -->

| Metric | Formula | Target *(Example)* | Frequency |
|---|---|---|---|
| EDR coverage | Assets with healthy agent / assets in inventory that require an agent | At least 99% | Monthly |
| Tamper protection | Agents with tamper protection on / all agents | 100% | Monthly |
| Mean time to triage, High and Critical | Average minutes from alert to triage | Under 60 | Monthly |
| Executed malware incidents | Count of true positives where malware executed | Trend down | Quarterly |
| Exclusions reviewed | Exclusions reviewed this quarter / all exclusions | 100% | Quarterly |
| User reporting rate | Reported simulated phish / delivered simulated phish | Trend up | Per campaign |

Worked coverage example for Quillmere Health Systems *(Example)*: the
asset inventory lists 320 laptops and 60 servers that require an agent,
380 assets in total. The EDR console shows 376 healthy agents, so
coverage is 376 / 380 = 98.9%, below the 99% target. The 4 missing
agents (3 laptops in repair, 1 new server) are investigated and either
fixed or recorded as justified.

Testing:

1. Run a harmless industry test file (for example the EICAR test file)
   on a sample of devices [quarterly] to confirm detection and alerting.
2. Include a malware or ransomware scenario in a tabletop exercise
   (`security/tabletop-exercise`) at least [annually].
3. Include EDR evasion checks in penetration tests where in scope.

## 11. Exceptions

<!-- Guidance: Exceptions for performance or compatibility are common on servers. Require a compensating control and an expiry for each one. -->

Exceptions (missing agent, audit-only mode, broad exclusion, macro
allowance) are requested with the security exception request
(DOC-ISMS-122) and approved at the authority the risk methodology
(DOC-ISMS-010 section 2.4) sets for the residual risk: the risk owner
for Low; the risk owner and department head for Medium (top management
if the risk category is Averse, DOC-ISMS-015 section 9 rule 1); top
management with a treatment decision for High, recorded in the risk
acceptance record (DOC-ISMS-019). Critical residual risk is not
approvable as an exception: treat it or stop the activity. Security
operations assess each request and the ISMS manager keeps the exception
register. Maximum duration is 12 months for Low or Medium and 6 months
for High; at expiry the exception is reassessed, and a renewal is a new
decision (DOC-ISMS-122 section 7).

| Exception ID | Asset and rule | Compensating control | Approved by | Expiry |
|---|---|---|---|---|
| EXC-MAL-001 *(Example)* | Legacy lab analyser PC cannot run EDR (MAL-CTL-006) | Isolated network segment, allow-listing, USB blocked, monthly offline scan | Lab manager (risk owner) and head of clinical services, residual risk Medium | 2027-03-31 |
| EXC-MAL-002 *(Example)* | Signed finance macros allowed for 12 users (MAL-CTL-005) | Trusted publisher only, files from internet still blocked | Head of finance (risk owner), residual risk Low | 2027-06-30 |

## 12. Size tiers

<!-- Guidance: The control objective is the same for every size. What changes is who watches the alerts and how much allow-listing is enforced. -->

| Aspect | Small: Quillmere Analytics Ltd | Medium: Quillmere Health Systems | Large: Quillmere Group |
|---|---|---|---|
| Tooling *(Example)* | Suite-native e-mail protection and EDR bundled with the productivity suite licence, protective DNS | Dedicated EDR, secure e-mail gateway, SIEM | EDR across IT, OT-aware monitoring for plants, SIEM with a security operations centre |
| Monitoring | Managed detection service, 24/7, Head of Engineering Operations as escalation | 3-person security team in office hours, managed service at night | 14-person security office with in-house SOC and on-call rota |
| Allow-listing | Audit mode on laptops, enforce on cloud build agents | Enforce on servers and clinical support laptops | Enforce on servers, HMI and plant terminals, rings for office staff |
| Removable media | Blocked, no exceptions | Blocked, scanning kiosk at each office | Scanning kiosks at each plant for OT maintenance media |
| Reporting | Monthly coverage export | Monthly dashboard to steering committee | Per-site metrics in group report |

## 13. Records and evidence

<!-- Guidance: Keep evidence that shows coverage, configuration and response. Screenshots age quickly; scheduled exports are better evidence. -->

| Record | Owner | Location | Retention *(Example)* |
|---|---|---|---|
| EDR coverage report reconciled with asset inventory | [@secops] | ISMS evidence folder | 3 years |
| EDR and e-mail policy configuration exports | [@secops] | Configuration repository | 3 years |
| Exclusion list with approvals and review dates | [@secops] | EDR console and exception register | Expiry plus 3 years |
| Alert and incident tickets | [@secops] | Ticketing system, incident register DOC-ISMS-021 | 3 years minimum |
| Detection test results | [@secops] | ISMS evidence folder | 3 years |
| Awareness completion and phishing results | [@awareness-lead] | Learning platform | 3 years |

Map each record to A.8.7 in the control evidence matrix (DOC-ISMS-033,
`isms/control-evidence-matrix`).

## 14. References

<!-- Guidance: Cite editions used. Confirm at each review that NIST SP 800-83 has not been replaced. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024, https://www.iso.org/standard/82875.html | Current, Amd 1 https://www.iso.org/standard/88435.html | Annex A control A.8.7 and related controls |
| ISO/IEC 27002:2022, https://www.iso.org/standard/75652.html | Current | Control guidance |
| NIST SP 800-83 Rev. 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops | July 2013 | Prevention and handling concepts (free public source, older but not withdrawn) |
| CIS Critical Security Controls v8.1 | June 2024 | Control 10 (malware defenses), cited by number and name only |
| MITRE ATT&CK | Current release | Technique IDs for detection coverage |

Related templates: `isms/endpoint-device-byod-policy` (DOC-ISMS-058),
`isms/secure-configuration-baseline` (DOC-ISMS-060),
`isms/backup-policy` (DOC-ISMS-061),
`isms/security-monitoring-procedure` (DOC-ISMS-064),
`isms/saas-productivity-security-baseline` (DOC-ISMS-075),
`compliance/incident-response-plan` (DOC-ISMS-020),
`isms/phishing-simulation-plan` (DOC-ISMS-074),
`security/soc-playbook`, `security/detection-rule-spec`,
`security/security-awareness-program`, `security/vulnerability-management-policy`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (Annex A control
A.8.7 and related controls) and ISO/IEC 27002:2022. Control numbers are
cited with short original labels. All requirements, tables and examples
are original and reproduce no text from ISO/IEC standards: obtain the
official standards from ISO (https://www.iso.org/standard/82875.html,
https://www.iso.org/standard/75652.html) or your national standards body.
CIS Controls are cited by number and name only. NIST SP 800-83 Rev. 1 is
a US government publication. Check for the current edition of each
reference before use.

Template licence: MIT.