3. From Compromise to Business Disruption: Preventing a Technical Incident from Becoming a Business Crisis

3.1 Damage Cannot Be Measured by “Number of Devices Encrypted”

The first table to build in ransomware response is not a list of the number of infected devices. It is a dependency table linking business operations, systems, data, dependencies, recovery procedures, and allowable downtime. For example, even if the sales system is running, if any one of identity authentication, DNS, certificates, the network, data integration, report output, payment, logistics, or the call center is lost, operations cannot practically resume.

Figure 5: The Difference Between “System Recovery” and “Business Recovery”

This order is not fixed, but it shows that there is a great deal of verification between having restored a server and being able to safely resume business operations. The recovery time objective (RTO) and recovery point objective (RPO) should be confirmed at the unit of business recovery, not at the unit of individual applications.

3.2 Handling Availability, Integrity, and Confidentiality Together

Ransomware tends to be discussed as a problem of availability, but in contemporary incidents all three properties are shaken at once.

Integrity is especially difficult. If recovery proceeds while it remains unknown from what period the intruder was present in the environment and which accounts, settings, or data were reached, there is a risk of reintroducing the attacker’s persistence mechanisms or alterations. This does not mean “delay recovery” — it means define a clean recovery boundary and proceed with priorities in place.

3.3 Making Dependencies Visible During Normal Operations

At minimum, record the following for each critical business function.

1. The business owner and the technical owner.
2. The impact of a stoppage and the allowable downtime.
3. Essential applications, data, identities, network, and external services.
4. Fallback procedures (paper, manual entry, an alternate site, handling of priority customers).
5. Recovery order, the party who signs off, and the criteria for judging recovery successful.
6. The location and generation of backups, and the keys, accounts, and procedures needed to restore them.

Do not confine this to a spreadsheet kept separate from the CMDB or BCP. Update the same information through change management, service owners, backup operations, and incident exercises. The inability to find this information in the field is itself a major risk that lengthens recovery time.

3.4 Backup Design: Recovery Capability, Not Mere Storage

Backups are important as the last line of defense against ransomware, but they are not a cure-all. If an intruder has obtained ordinary administrative privileges, they may be able to reach online, rewritable backups, snapshots, and management consoles. CISA recommends measures including protecting backups, regularly testing restoration, and maintaining multiple copies of critical data. [S01]

Design Checklist

• Whether backup deletion, retention changes, or encryption-key operations can be performed using only the same privileged credentials as production identities.
• Whether the state of backups and restoration procedures can be checked even during a production network outage.
• Which of immutability, isolation, or offline storage is applied to which critical data.
• Whether restoration testing covers applications, authentication, dependent services, performance, and data integrity, rather than a single file.
• Whether the case is anticipated in which the licenses, DNS, certificates, secrets, configuration management, or administrative endpoints needed for restoration are themselves lost.
• Which business procedure will be used to make up for data lost in the final hours or days.

Operational judgment: The “success” of a backup is not measured by a job-completion notification. It is a success only once the specified business operation can be safely carried out, within the specified time, in the restored environment.

3.5 Division of Labor Between Business Continuity and Crisis Response

During an incident, mixing technical investigation and management decision-making in the same meeting slows both down. A structure that separates roles while integrating information is needed.

3.6 How Payment Should Be Positioned

Whether to pay cannot be decided by technical argument alone. There is no guarantee that a decryption tool will be provided, no guarantee that stolen data will be deleted, and no guarantee against renewed attack. In addition, applicable law, sanctions designations, insurance terms, consultation with investigative authorities, contracts with business partners, and social responsibility are all relevant. CISA’s guidance also emphasizes that payment does not guarantee recovery and that organizations should coordinate with legal counsel, investigative authorities, and others. [S01]

This report’s position is clear. Ransom payment must not be designed as part of a technical recovery measure. It is a management and legal decision made under extreme conditions, and it does not substitute for backups, recovery exercises, alternative operations, or scope-of-compromise investigation.

3.7 Questions to Verify Through Exercises

• When a suspected compromise of the identity infrastructure arises late on a Sunday night, who approves suspending accounts?
• When a backup administrator’s identity is suspect, which alternate route is used to access the recovery infrastructure?
• Who makes the decision to shut down the customer portal, and who notifies business units of the impact?
• Upon finding a claim posted on a leak site, who preserves and verifies it, and who halts outbound communications?
• What confirms safety sufficiently to announce “recovered” after 72 hours?

The purpose of an exercise is not to trace a perfect script. It is to find, during normal operations, deficiencies in contact lists, ambiguities in authority, insufficient assumptions about restoration, and differences in terminology with business units.