ISO 27001 Ransomware Resilience: Prevent, Contain and Recover

Ransomware is not only a malware problem. A serious event can combine stolen credentials, privilege escalation, data theft, destructive actions, service interruption, extortion and public disclosure. Preventing one malicious file from running is useful, but resilience depends on how people, identity, networks, suppliers, backups, incident decisions and recovery work together.

ISO/IEC 27001 does not promise that ransomware will never succeed. It provides a management system for identifying the relevant risk, choosing controls, assigning ownership, evaluating performance and improving after evidence. The practical objective is to reduce the likelihood and impact of an attack while preserving the ability to make sound decisions under pressure.

This guide is AuditPrepared implementation guidance, not a reproduction of ISO requirements.

Describe the ransomware scenario precisely

“Ransomware attack” is too broad for useful treatment. Build scenarios around the organisation’s services and attack paths. For example:

Compromised remote-access credentials allow an attacker to enter the corporate environment, obtain administrative privileges, extract sensitive customer data and disrupt the production service and connected backups.

That statement identifies access, privilege, confidentiality, availability and recovery concerns. It supports decisions about identity controls, segmentation, monitoring, backup separation, incident response and supplier responsibilities.

Develop more than one scenario where the consequences differ. A compromised employee laptop, a cloud-administrator account, a managed-service provider, an internet-facing application and a factory endpoint may demand different treatment.

Use the risk score calculator when it aligns with the approved method, while retaining the narrative and uncertainty behind the score.

Build prevention as a control system

No single safeguard is a ransomware control. Use layers that address entry, execution, privilege, movement and impact.

Identity and privilege

Require strong authentication for remote and privileged access, control enrolment and recovery, remove dormant accounts, limit standing administrative rights and review service accounts. Monitor unusual authentication and privilege use. The MFA scope and audit-evidence guide explains why deployment counts alone do not prove effective coverage.

Exposure and vulnerability management

Maintain a current understanding of internet-facing services, supported software and material vulnerabilities. Prioritise remediation using exploitability, exposure, asset importance and available safeguards—not severity labels alone. Govern emergency changes and preserve evidence of validation.

Endpoint and application controls

Use appropriate malicious-code protection, application restrictions, secure configuration and behavioural detection. Protect security tooling from unauthorised alteration. Define how alerts are triaged, who can isolate an endpoint and how false positives are resolved.

Network and service boundaries

Limit unnecessary connectivity and administrative paths. Separate user, server, backup and management environments where risk warrants it. Review supplier tunnels, remote tools and cloud trust relationships. Segmentation is credible when tested from the perspective of plausible attack movement.

People and reporting

Give personnel clear ways to report suspicious messages, unexpected authentication prompts, unusual encryption, missing files and extortion messages. Role-based exercises should include service desk, administrators, executives, legal, privacy, communications and recovery teams.

The Annex A control lookup can help teams explore relevant control purposes, but applicability and implementation must follow the organisation’s risk decisions.

Protect recovery from the attack

Backups are valuable only when the organisation can restore trusted services within business needs. Attackers may seek backup credentials, consoles, repositories and retention settings. Design recovery so that one compromised identity or management plane cannot silently destroy every viable copy.

Define:

• which data, configurations, keys and infrastructure definitions are essential;
• recovery-point and recovery-time needs approved by service owners;
• copy separation, access restrictions and administrative roles;
• immutable or offline protection where appropriate;
• monitoring for deletion, encryption or policy change;
• integrity and malware considerations before restoration; and
• the order in which dependencies must return.

The CISA StopRansomware Guide recommends maintaining offline, encrypted backups of critical data and testing their availability and integrity in recovery scenarios. Apply that principle proportionately to the organisation’s architecture.

A successful backup job is implementation evidence. A timed exercise that restores a representative service, validates data and records business acceptance is operating evidence.

Prepare decisions before the crisis

A response plan should define authority, not attempt to predict every technical step. Establish who can:

• isolate accounts, devices, networks and services;
• invoke emergency change and continuity arrangements;
• engage external responders and insurers;
• preserve and acquire evidence;
• assess legal, contractual and privacy obligations;
• communicate with personnel, customers, regulators and media;
• approve restoration and return to service; and
• decide the organisation’s position on an extortion demand.

Ransom and disclosure decisions involve legal, ethical, operational and sanctions considerations. They should be directed by authorised leadership with competent legal and law-enforcement input where applicable. Do not leave the decision to a technical responder during the event.

The incident-management evidence guide shows how to preserve classification, decisions, timelines, communications and improvement records.

Detect and contain with a common operating picture

Define observable triggers and escalation thresholds. Relevant sources may include identity, endpoint, network, cloud, application, email, backup and supplier monitoring. Retain enough context to connect alerts across systems.

During an event, maintain an authoritative timeline with known facts, uncertainty, actions, approvals and affected assets. Separate confirmed compromise from assumptions. Containment decisions should consider both stopping the attacker and preserving essential evidence.

Service restoration can conflict with investigation. Record who resolved the trade-off and why. Restoring a server without addressing stolen credentials, persistence or compromised administration may recreate the incident.

Recover by trusted stages

Recovery should follow an approved order based on dependencies and business priority. Before return, confirm that:

• the intended recovery point is understood;
• restored data and configurations pass integrity tests;
• compromised identities and access paths are addressed;
• required security controls and monitoring are operating;
• unresolved exposure has an authorised decision; and
• the service owner accepts the recovered outcome.

Use clean administrative workstations and controlled credentials where the risk analysis requires them. Preserve evidence of versions, sources, actions and validation. Document temporary safeguards and expiry dates.

Test restoration at service level, not only file level. Include identity, name resolution, certificates, external integrations, supplier access and monitoring. The exercise should reveal whether teams can reconstruct a trustworthy operating environment.

Include suppliers and shared responsibility

Cloud and managed-service providers may operate critical layers, but the organisation retains responsibilities for configuration, identity, data, contracts and coordination. Define notification time, evidence support, containment authority, recovery duties and communication channels.

Sample supplier assurance against the real service and scope. A general certificate does not prove that the contracted recovery design or tenant configuration meets the organisation’s needs. The supplier security lifecycle guide provides a wider governance model.

Evidence an auditor should follow

Design evidence may include risk scenarios, treatment decisions, recovery requirements, response authority, architecture standards and supplier terms. Operating evidence may include:

• current privileged-access reviews;
• remediation records for exposed vulnerabilities;
• blocked or investigated security events;
• backup protection and deletion alerts;
• successful service restoration with measured results;
• exercise decisions and improvement actions;
• supplier notification tests; and
• metrics reported to management.

Sample across prevention, detection and recovery. Include a high-impact service, a privileged identity, a backup repository, a supplier dependency, a recent alert and a failed or delayed recovery test. Trace each sample to source-system evidence rather than relying only on summaries.

Pass, partial and fail examples

Pass: Ransomware scenarios were service-specific, controls addressed multiple attack stages, recovery was isolated and tested, and exercises produced owned improvements.

Partial: Endpoint protection and backups existed, but privileged access and supplier recovery roles were weakly evidenced and restoration had not been tested as a complete service.

Fail: Management assumed antivirus and successful backup jobs were sufficient, while no authorised containment, extortion or trusted-recovery decisions were defined.

Measure resilience, not activity alone

Useful measures include critical assets with tested restoration, privileged accounts outside approved controls, exposed vulnerabilities beyond risk-based targets, high-severity alerts assessed within expectations, recovery exercises meeting business needs and overdue ransomware improvement actions.

Avoid reporting only training completion, tool deployment or backup-job success. Those measures show activity or implementation. Management needs evidence that the organisation can prevent common paths, detect abnormal behaviour, contain compromise and restore trusted services.

Practical conclusion

ISO 27001 helps against ransomware by governing a connected set of risk decisions and controls. Build scenarios around important services, protect identity and recovery paths, define authority before the event, test complete restoration and improve from evidence.

The aim is not to claim total prevention. It is to make compromise harder, limit its reach and recover with confidence when prevention is not enough.

This article was cross-checked against the official ISO/IEC 27001 overview and CISA guidance. The control architecture, evidence model and sampling approach are original AuditPrepared guidance.