Malware Protection Standard Template (ISO/IEC 27001 A.8.7)

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.

Document control

Approvals

Revision history

Contents

• 1. Purpose and scope
• 2. Roles and responsibilities
• 3. Threat picture
• 4. Layered control model
• 5. Endpoint and server protection requirements
• 6. E-mail, web and file controls
• 7. Application allow-listing, macros and scripts
• 8. Detection and response
• 9. User awareness
• 10. Coverage, metrics and testing
• 11. Exceptions
• 12. Size tiers
• 13. Records and evidence
• 14. References
• Standard and licence note

1. Purpose and scope

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:

2. Roles and responsibilities

3. Threat picture

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

4. Layered control model

5. Endpoint and server protection requirements

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

7. Application allow-listing, macros and scripts

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

8. Detection and response

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

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

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

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).

12. Size tiers

13. Records and evidence

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

14. References

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.