How to build a ransomware threat model for the business

Organizations often have incident response playbooks and backup strategies but lack a systematic map of what ransomware could actually control in their environment. A ransomware threat model fills this gap by mapping the specific control domains that ransomware operations exploit across the attack lifecycle. Without this mapping, response planning operates on assumptions about entry points, lateral movement paths, and recovery dependencies that may not reflect the actual environment.

This is a ransomware-focused application of threat modeling — a structured practice that identifies assets, enumerates threats, evaluates controls, and prioritizes mitigations based on impact and likelihood. Standard threat modeling frameworks address technical and governance concerns; this article applies that discipline specifically to the attack patterns, extortion leverage, and recovery dependencies that define ransomware operations. The OWASP Threat Modeling Cheat Sheet provides useful structure on assets, mitigations, and validation that applies throughout (Source: OWASP, https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html).

The CISA Ransomware Guide recommends that organizations conduct ransomware-specific risk assessments encompassing entry points, lateral movement paths, backup integrity, and recovery dependencies as preconditions for effective response planning (Source: CISA, https://www.cisa.gov/stopransomware/ransomware-guide). The threat model described here represents one structured approach to satisfying that recommendation, organized around the control domains ransomware operations consistently exploit.

What a ransomware threat model is and is not

A ransomware threat model maps what an attacker could control at each stage of a ransomware operation in your specific environment. It differs from a generic threat model in its focus: it concentrates on the control domains ransomware exploits — initial access, lateral movement, data staging, extortion leverage, and recovery dependencies — and it maps decision rights and organizational pressure points alongside technical controls.

The model is not a technical vulnerability assessment. Vulnerability scanning identifies specific flaws; the threat model identifies what an attacker could access and control regardless of the specific exploitation method. It is also not a generic business impact analysis. Business impact assessments catalog operational effects; the threat model maps the specific leverage an attacker would hold during a ransomware operation and traces that leverage to critical business services.

The most effective approach treats this as operational reconnaissance rather than theoretical modeling. Map what exists today, not what should exist according to policy. The model reveals gaps between intended controls and actual access patterns — and connects those gaps to the business services whose disruption or exposure would create pressure to pay.

Mapping access and entry points

The Verizon 2024 Data Breach Investigations Report identifies credential abuse and exploitation of public-facing applications as leading ransomware initial access methods (Source: Verizon DBIR 2024, Figure 7 / pp. 14–16, https://www.verizon.com/business/resources/reports/dbir/). These two categories are a practical starting point for most enterprise environments, but initial access is broader than externally exposed services alone.

Map the full range of realistic entry vectors for your environment:

For each access vector, document the authentication mechanism involved, the initial privilege level an attacker would obtain, and which internal resources become reachable from that position.

Document service accounts with external access capabilities. Many ransomware operations exploit service accounts because they often carry broader access than intended and attract weaker monitoring. Map which service accounts can authenticate externally, what resources they access, and whether their credentials are stored in discoverable locations.

Map credential storage and distribution mechanisms. Document where credentials are stored, how they are distributed to users and systems, and which credential stores would be accessible from initial compromise positions. This includes password managers, certificate stores, and credentials cached on workstations.

Verification step: Use external reconnaissance tools to validate which services are currently exposed — this checks for services that may have been missed in your inventory. Note that this validates exposure of external-facing services; it does not confirm the completeness of identity pathways, third-party access grants, or endpoint credential exposure, which require separate review.

Mapping lateral movement and privilege paths

Map the paths from initial access positions to high-value targets. For each entry point, document which systems an attacker could reach, what credentials or techniques would enable that movement, and which intermediate systems serve as stepping stones to critical resources.

Focus on credential reuse patterns and privilege inheritance. Many environments contain credentials that authenticate against multiple systems, or accounts that accumulate elevated access through group membership over time. Map which credentials provide access to multiple systems and which privilege escalation paths exist through group membership or delegation.

Document trust relationships between systems and domains carefully. Active Directory trusts, cloud service principals, and certificate authorities are distinct mechanisms that require individual analysis:

For each trust relationship, model trust direction, effective permissions, the authentication artifacts an attacker would need, and how the configuration would need to look for lateral movement to succeed. Do not treat trust relationships as uniformly permitting free lateral movement; the actual exposure depends on configuration in each case.

Map administrative access patterns. Document which accounts have administrative access to multiple systems, where those accounts authenticate from, and whether administrative access requires step-up authentication. Administrative accounts represent high-value targets because they provide broad access once compromised.

Decision criteria: Prioritize mapping paths to systems that contain sensitive data, provide network infrastructure services, or control backup and recovery capabilities. These represent the highest-value targets for ransomware operations and the systems whose compromise most directly determines recovery complexity.

Mapping data exfiltration exposure

Map what data is accessible from potential compromise positions and how exfiltration could occur. Document data repositories, the access controls protecting them, and which compromise scenarios would provide access. Include structured databases, file shares, cloud storage, collaboration platforms, and backup repositories.

Document data classification and regulatory exposure. Map which data sets would create regulatory obligations if compromised, what notification requirements would apply, and what penalties could result. This is one component of the extortion leverage an attacker would hold — but not the only one.

Recognize that data-extortion scenarios can occur without encryption. Ransomware groups increasingly exfiltrate data and threaten publication as a standalone pressure tactic, independent of whether they encrypt production systems. Map which data compromise scenarios would create regulatory, legal, or reputational pressure to comply with demands even if operations remain available.

Map network egress paths and monitoring coverage. Document how data could leave the environment, what monitoring exists for outbound transfers, and what volume of data could be exfiltrated before detection. Include both legitimate channels that could be abused and potential covert channels.

Document backup accessibility from potential compromise positions. Map which backup systems would be accessible from various compromise scenarios and whether backups are stored in ways that prevent access from compromised production systems. Backup compromise shifts a ransomware event from a disruption into a recovery crisis.

Implementation step: Create an access matrix showing which compromise positions provide access to which data repositories. This reveals whether critical data is adequately segmented from likely compromise scenarios and where data-only extortion exposure is highest.

Mapping extortion leverage and pressure vectors

Map the operational and regulatory leverage an attacker would hold at execution. Anchor this analysis in critical business services and their tolerable disruption windows. For each service, document which underlying systems must be available, what the operational impact timeline looks like if those systems are unavailable, and which stakeholders would feel the most acute pressure.

Document regulatory and legal exposure from data compromise. Map which compromised data sets would trigger regulatory notifications, what penalties could apply, and what legal obligations would arise. Regulatory exposure is one component of extortion leverage, not the whole of it.

Map reputational and competitive exposure. Document which data compromise scenarios would create reputational damage, competitive disadvantage, or customer trust issues. These factors often drive payment decisions even when operational recovery is technically possible.

Document decision-making authority and pressure points. Map who has authority to make payment decisions, what approval processes exist, and which stakeholders would advocate for payment versus recovery. Extortion effectiveness depends on organizational decision dynamics as much as technical impact.

A single control investment can contribute to multiple outcomes simultaneously — preventing initial access, containing lateral movement, reducing exfiltration exposure, and shortening recovery time all reduce extortion leverage. Model controls against the full leverage picture rather than treating prevention, containment, recovery, and exposure reduction as separate programs.

Assessment question: If your most likely compromise scenarios occurred tomorrow, what would be the primary source of pressure to pay — operational disruption of critical business services, regulatory exposure from exfiltrated data, or reputational damage? And could that pressure exist without any encryption occurring? This determines which defense investments provide the most leverage reduction.

Mapping recovery dependencies and decision rights

Map what systems, vendors, and decision rights are on the critical path to recovery. Anchor recovery mapping in business services rather than infrastructure components: identify which business services must be restored to what functional level within their tolerable disruption window, and then trace the systems, credentials, and decisions required to reach that state.

Document vendor and service provider dependencies. Map which restoration activities require vendor support, what service level agreements govern that support, and whether vendors would be available during a crisis. Many recovery timelines are constrained by external resources that may not be available at the moment they are needed.

Map backup integrity and accessibility with specificity. Document backup locations, access mechanisms, encryption key storage, and whether backups would be accessible during various compromise scenarios. Backup availability on paper differs from backup availability under attack conditions.

Document decision authority for recovery priorities. Map who decides which systems to restore first, what approval is required for major recovery decisions, and whether decision makers would be available during a crisis. Recovery frequently stalls on organizational decisions rather than technical challenges.

Map resource requirements for recovery execution. Document what personnel, equipment, and facilities would be needed, whether those resources would be available during a crisis, and what alternative arrangements exist.

Critical verification — restore a business service, not just a backup: Test recovery by attempting full restoration of a business service from an isolated network environment. This validation should confirm:

The goal is to demonstrate that a specific business service can be recovered to an acceptable state within a defined time window — not merely that backup files can be read.

Using the model

The threat model output organizes into three program investment areas. Access and lateral movement findings feed controls focused on prevention and containment speed. Recovery dependency findings feed resilience programs. Extortion leverage findings feed economic response programs including cyber insurance, legal readiness, and communication planning. Many controls contribute across all three areas simultaneously.

Use the model to prioritize defense investments. Focus first on controls that break the most damaging attack paths relative to your critical business services, rather than attempting to address every identified gap. The model reveals which investments provide the most protection against realistic attack scenarios in your specific environment.

Update the model when major infrastructure changes occur. New cloud services, network architecture changes, and significant application deployments can create new attack paths or alter recovery dependencies. Treat the threat model as a living document rather than a point-in-time assessment, and assign review dates to each domain.

Use threat model findings to validate incident response assumptions. Many IR plans assume capabilities or access patterns that do not reflect the actual environment. The threat model provides the operational reality check that makes IR planning more effective.

Threat model template

The template below records domains, gaps, and owners. Owners listed are examples; most domains require cross-functional participation rather than a single team. Add a review date and validation criteria for each row. Supplement the template with scenario records as described below.

Scenario record example

Standard threat modeling practice recommends documenting specific scenarios that link an attacker capability to an asset, existing controls, impact, and mitigation — then tracking residual risk and validation (Source: OWASP Threat Modeling Cheat Sheet, https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). The following example illustrates how a threat model entry should be extended from a domain assessment into an actionable scenario record.

Scenario: Credential theft via phishing leads to domain administrator compromise and encryption of ERP system.

Organizations should create scenario records for each realistic entry point identified in their environment, connecting the initial access vector through to the business service impact and recovery path.

Sources