ISO 27001 A.8.9–8.16: Malware Protection, Backup, and Logging

The operational backbone

While controls A.8.1 through A.8.8 cover fundamental security mechanisms (endpoints, access rights, malware, vulnerabilities), A.8.9 through A.8.16 go deeper into operational IT management. They govern how systems are configured, backed up, monitored, and supplied with adequate resources.

For a company with around 100 employees, these controls are often a mix of "we already do that" and "we never documented it." The challenge lies less in the technical implementation and more in systematic documentation and regular review.

A.8.9: Configuration Management

What the standard requires

Configurations, including security configurations, of hardware, software, services, and networks must be established, documented, implemented, monitored, and reviewed.

A new control with high relevance

A.8.9 is one of the new controls in ISO 27001:2022 and addresses a common problem: systems are installed, configured, and then forgotten. Over time, the actual configuration drifts from the planned one, security settings are loosened, unnecessary services are activated, and nobody notices.

Implementation

Secure baselines: Define a secure baseline configuration for each system type (Windows servers, Linux servers, Windows clients, network switches, firewalls, cloud services). Use CIS Benchmarks or BSI IT-Grundschutz recommendations as guidance.

A baseline for a Windows server covers, for example: disabled unnecessary services, configured firewall rules, enabled audit logging, disabled Remote Desktop for non-admins, configured password policies, enabled full-disk encryption, and current patches.

Control configuration changes: Every change to a production system's configuration must go through the change management process (see A.8.32). This applies even to seemingly minor changes like opening a firewall port.

Configuration monitoring: Ideally, configurations are monitored automatically so deviations from the baseline are detected. Tools such as Microsoft Defender for Cloud, Chef InSpec, Ansible, or SCAP scanners can accomplish this. For a company with around 100 employees, a manual review of configurations at regular intervals (semi-annually) is also an acceptable approach.

A.8.10: Information Deletion

What the standard requires

Information stored in information systems, devices, or other storage media must be deleted when no longer needed.

More than deleting a file

Simply deleting a file only removes the directory entry, not the data itself. A.8.10 requires that deletion methods match the protection requirements of the data.

Classification-based deletion: The deletion method depends on the data classification. Public data can be deleted normally. Confidential data requires secure overwriting. Strictly confidential data requires certified deletion or physical destruction of the medium.

Deletion concept: Document a deletion concept that specifies for each data type: retention period (how long must the data be kept at minimum?), deletion deadline (when must the data be deleted at the latest?), and deletion method (how is it deleted?).

Cloud data: For cloud services, it must be ensured that data is deleted by the provider after contract termination. Request written confirmation of deletion.

Alignment with DSGVO (GDPR): The deletion concept must be consistent with GDPR requirements. Personal data may only be stored as long as the processing purpose requires.

A.8.11: Data Masking

What the standard requires

Data masking must be applied in accordance with the topic-specific policy on access control and other related policies as well as business requirements, taking into account applicable legislation.

Relevance

A.8.11 is a new control and primarily concerns organizations that work with sensitive data in test or development environments. When production data (customer data, personal data) is used in test environments, it must be masked or pseudonymized.

For a company with around 100 employees, this control is relevant if you develop your own software or if off-the-shelf software customizations are tested with real data. If you exclusively use standard software without customizations, the control has lesser significance.

A.8.12: Data Leakage Prevention

What the standard requires

Data leakage prevention measures must be applied to systems, networks, and other devices that process, store, or transmit sensitive information.

Implementation

Data Leakage Prevention (DLP) prevents confidential data from leaving the organization in an uncontrolled manner. For a company with around 100 employees, DLP does not need to be implemented as an enterprise solution with automatic content recognition. A pragmatic approach includes:

Email-based DLP: Rules that block or prompt for confirmation when large files or certain file types are sent to external recipients. Microsoft 365 offers built-in DLP capabilities.

Cloud storage control: Blocking unauthorized cloud storage services. Only approved services may be used for data transfer.

USB control: Restricting the use of USB storage devices.

Classification labeling: Confidential documents are labeled so employees handle them consciously.

A.8.13: Information Backup

What the standard requires

Backup copies of information, software, and systems must be maintained and regularly tested in accordance with the agreed topic-specific policy on backup.

The backup plan

A documented backup plan contains for each system:

What is backed up: Full system image or data only? Configuration files? Databases?

How often: Backup frequency must match the RPO (see BIA). Daily full backups and hourly incremental backups are a good standard for business-critical systems at most companies with around 100 employees.

Where to: Primary backup storage (local or on a dedicated backup server), secondary storage at another location or in the cloud. The 3-2-1 rule (3 copies, 2 different media, 1 copy offsite) is the recognized best practice.

How long: Retention periods for backups. Daily backups are typically kept for 30 days, weekly backups for 3 months, monthly backups for 1 year. Exact periods depend on regulatory and business requirements.

Encryption: Backups that leave the secured area (offsite location, cloud) must be encrypted.

Ransomware protection: At least one backup copy must be protected against ransomware. This means: not reachable from the network (air gap), immutable (immutable backup), or protected by access restrictions such that an attacker with admin rights on the network cannot delete the backups.

Restore tests

The critical point where many organizations fail: backups that have never been tested are worthless. Regular restore tests verify that backups are complete, consistent, and recoverable within the RTO. In ISMS Lite, restore tests can be scheduled, documented, and linked to the backup plan so overdue tests are immediately visible.

Test frequency: Quarterly for business-critical systems, at least annually for all systems with backups.

Test documentation: Date, system tested, backup date, recovery duration, result (successful/failed), issues encountered, and actions taken.

A.8.14: Redundancy of Information Processing Facilities

What the standard requires

Information processing facilities must be implemented with sufficient redundancy to meet availability requirements.

Implementation

Redundancy planning is based on the BIA. Systems with short RTOs need more redundancy than systems whose outage can be tolerated for days.

Server redundancy: For business-critical servers (ERP, email, database): clustering, hot standby, or at least a prepared recovery environment. Virtualization greatly simplifies redundancy because VMs can be quickly migrated to other hosts.

Storage redundancy: RAID systems for local data storage. Replicated storage systems for higher requirements.

Network redundancy: Redundant switches for the core network. A second internet provider or mobile failover.

Site redundancy: For organizations with very high availability requirements: a second site that can take over operations if the primary site fails completely. For a company with around 100 employees, this is often impractical, but cloud-based disaster recovery solutions offer a cost-effective alternative.

A.8.15: Logging

What the standard requires

Logs that record activities, exceptions, faults, and other relevant events must be produced, stored, protected, and analyzed.

Why logging matters so much

Logs are the foundation for three critical functions: detecting security incidents (monitoring), forensic investigation after incidents (incident response), and demonstrating compliance (audit). Without meaningful logs, you are flying blind.

What must be logged

Authentication events: Successful and failed logins, account lockouts, password changes. These logs are the first point of reference for detecting brute-force attacks and unauthorized access.

Privileged account activities: All actions by admin accounts must be logged: system changes, user management, configuration changes.

System events: Service starts and stops, system errors, security warnings, firewall events.

Changes to security-relevant configurations: Firewall rule changes, group policy changes, access rights modifications.

Data access to sensitive information: Access to confidential files and databases, where technically feasible.

Protecting the logs

Logs are only useful if they are trustworthy. An attacker who can manipulate logs covers their tracks.

Centralized collection: Logs are sent from source systems to a central log server or SIEM system. There they are separated from the source system and cannot be easily manipulated.

Integrity protection: Logs are provided with timestamps and checksums. Modifications are detectable.

Access restriction: Only authorized persons have access to logs. Administrators whose activities are logged should ideally have no write access to the logs (separation of duties).

Retention period: Define a retention period for logs. Typical: 90 days available online, 1 year archived. The exact duration depends on regulatory requirements and storage capacity.

Log analysis

Collecting logs without analyzing them is almost as bad as not logging at all. Define how and how often logs are analyzed:

Automated alerts: Automatic alerts are configured for critical events (multiple failed logins, admin actions outside business hours, access to honeypot files).

Regular manual review: Weekly spot checks of the most important logs by IT or the Information Security Officer (ISO).

Event-driven analysis: When a security incident is suspected, the relevant logs are systematically evaluated.

A.8.16: Monitoring Activities

What the standard requires

Networks, systems, and applications must be monitored for anomalous behavior, and appropriate actions taken to evaluate potential information security incidents.

Distinction from logging

A.8.15 (Logging) describes the recording of events. A.8.16 (Monitoring) goes a step further and demands active surveillance and analysis. Logging is passive (recording), monitoring is active (detecting and responding).

Implementation for around 100 employees

A full Security Operations Center (SOC) is generally not economically viable for a company with around 100 employees. Pragmatic alternatives:

Managed Detection and Response (MDR): An external service provider monitors your systems around the clock and alerts on suspicious activity. Many EDR solutions offer MDR as an add-on service.

SIEM-Light: A lightweight SIEM system (e.g., Wazuh, Graylog) collects logs centrally and evaluates them with predefined rules. For a company with around 100 employees, this is often sufficient but requires someone to review the alerts.

Network monitoring: Tools such as Nagios, Zabbix, or PRTG monitor system availability and performance. Anomalous network activity (unusually high data transfers, communication with known malware C2 servers) is detected.

Additional controls: A.8.11, A.8.12, and nuances

Clock synchronization (implicit in A.8.15)

All systems must use the same time source. If system clocks diverge, logs cannot be correlated. Forensic analysis becomes impossible when the firewall log shows a different time than the server log.

NTP configuration: All systems synchronize their clocks against a reliable NTP server (e.g., ptbtime1.ptb.de or pool.ntp.org). Define the NTP server as a standard in the baseline configurations (A.8.9).

Control of privileged utilities

System utilities with extensive permissions (registry editor, disk management, network sniffers) should not be available to normal users on endpoints. On servers, access to these tools should be restricted to the necessary administrators, and their use should be logged.

Typical audit findings for A.8.9–A.8.16

Finding 1: No documented baseline configurations

Systems are installed and configured, but there is no documented standard against which the configuration can be checked. Each administrator configures at their own discretion.

Finding 2: Restore tests missing or not documented

Backups are created, but there is no evidence of regular restore tests. IT assures that "everything would work" but cannot prove it.

Finding 3: Logs are not analyzed

A central log server exists, but logs are not regularly analyzed. There are no defined alerts and no manual review. Logs serve only for post-incident analysis, not for detection.

Finding 4: No redundancy for business-critical systems

Despite short RTOs in the BIA, there is no redundancy for business-critical servers. A hard drive failure on the ERP server would lead to a multi-day outage, even though the BIA specifies a maximum of 4 hours.

Finding 5: Clocks not synchronized

System clocks deviate by several minutes from each other. Log entries from different systems cannot be correlated in time.

How ISMS Lite supports the evidence

Backup plan documentation: Document the backup plan for each system including interval, retention period, storage location, and RPO. ISMS Lite reminds you of due restore tests.

Restore test protocols: Document restore tests in a structured format with results and actions — linked to the respective backup plan.

Configuration standards: Documentation of baseline configurations per system type with links to affected assets.

Logging policy: Create your logging policy with AI assistance, covering retention periods, log sources, and analysis procedures.

Action tracking: All findings and actions are centrally recorded, assigned, and scheduled for follow-up.

Further reading

• Backup strategy and restore tests: Data protection that works in an emergency
• Logging and monitoring strategy: What you should log and monitor
• Data backup following the 3-2-1 principle: Implementing the BSI recommendation
• Change management in the ISMS: Managing changes securely
• Deletion concept under GDPR: Retention periods and secure deletion