iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A useful ransomware threat model connects business-critical services to the assets and dependencies they require, shows how an attacker could enter and spread, and assigns controls, response decisions, and recovery priorities to each path. Build it as a living resilience model—not as a promise that ransomware can be prevented.
What the model must show
Ransomware is not limited to an encryption event. NIST IR 8374 Rev. 1 defines it as a malicious attack in which attackers encrypt an organization’s data and demand payment to restore access. Modern campaigns may also steal data and demand payment to prevent disclosure. CISA warns that these incidents can leave organizations unable to access data needed to operate and deliver mission-critical services.
Your finished model should let leaders answer four questions for every important service:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Which service, data, people, and technology could be disrupted?
- Which entry points and trust relationships could let an attacker reach them?
- Which safeguards block, detect, or limit each step?
- Who decides containment, notification, restoration, and reconnection?
1. Set scope and governance before drawing attack paths
Write down the business units, sites, cloud tenants, legal entities, and critical services included in the model. Scope should include corporate IT and, where relevant, operational technology, third-party connections, and shared management platforms. Record exclusions and the reason for each so a boundary is not mistaken for protection.
#1 Best Overall
Assign named decision makers:
- An executive owner who accepts risk and authorizes major business decisions.
- System and service owners who can confirm dependencies and recovery priorities.
- A security lead who maintains scenarios, controls, and detection requirements.
- A continuity or resilience lead who owns downtime tolerances and recovery order.
- Legal and privacy contacts who assess notification and disclosure obligations.
- Communications decision makers who can approve internal, customer, regulator, and public messages.
NIST IR 8374 Rev. 1, a CSF 2.0 community profile published June 11, 2026, organizes ransomware outcomes across Govern, Identify, Protect, Detect, Respond, and Recover. Use those functions to assign ownership, but keep the model tied to your actual services and architecture.
2. Inventory assets and dependencies by business service
Start with the service rather than a device list. For each critical service, record the assets that make it work and the dependencies required to restore it. CISA says organizations should know which systems are critical for safety, revenue, or mission services and document their interdependencies.
Capture at least these asset categories:
- Endpoints, servers, identity providers, privileged accounts, and administrative workstations.
- SaaS applications, cloud resources, data stores, and externally exposed services.
- Network zones, remote-access systems, management planes, and security tooling.
- Operational technology or safety systems where disruption could create physical consequences.
- Vendors, service providers, software-update channels, and third-party connections.
- Backup systems, backup credentials, storage locations, and restoration infrastructure.
For every item, record its business owner, technical owner, authentication path, network zone, data sensitivity, upstream and downstream dependencies, and recovery dependency. Note shared credentials and common administration paths: a single identity or management plane can connect otherwise separate services.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems3. Define attacker objectives and plausible entry paths
Model what an attacker is trying to achieve, not only the malware they might use. Include denial of access, operational disruption, theft of sensitive data, and extortion based on disclosure.
Rank #2
Initial-access scenarios
- Credential compromise through phishing, password reuse, token theft, or social engineering.
- Exploitation of an internet-facing service or unpatched appliance.
- Abuse of remote-access tools, VPNs, or exposed administration interfaces.
- Malicious removable media or unauthorized software.
- Compromise of a vendor, service provider, or trusted connection.
Post-compromise objectives
- Escalate privileges and obtain domain, cloud, or backup administration.
- Discover high-value systems, data stores, security tools, and recovery assets.
- Move laterally across flat network segments or shared management paths.
- Disable monitoring or backups, target backup credentials, and prepare encryption.
- Exfiltrate data before encryption and create an extortion decision.
4. Draw complete attack paths and trust boundaries
For each scenario, draw a chain from initial access to business impact. A useful sequence is:
- Initial access, such as a stolen credential or exploited exposed service.
- Identity takeover and privilege escalation.
- Discovery of hosts, shares, cloud resources, backups, and administrators.
- Lateral movement through network, identity, remote-access, or vendor trust.
- Backup targeting and security-control evasion.
- Data theft, encryption, service interruption, or extortion.
- Operational, financial, safety, contractual, regulatory, and reputational consequences.
Mark every trust boundary, shared credential, flat segment, internet-facing system, third-party connection, and management plane on the diagram. Attach the business service and owner to the final impact node. This makes it possible to see where one compromised account could cross several boundaries.
5. Estimate impact and rank scenarios
For each attack path, document the maximum tolerable downtime, safety effects, revenue and productivity loss, contractual and regulatory exposure, harm from data disclosure, recovery cost, and cascading dependencies. Distinguish a service that can be restored independently from one that requires an identity provider, network, vendor, or specialized equipment first.
Rank scenarios using your organization’s risk appetite and evidence from inventories, incident history, exercises, and financial or downtime estimates. CISA and NIST do not prescribe one universal probability or loss formula. Avoid inserting a generic ransomware percentage or average ransom; use your own assumptions and label uncertainty.
6. Map safeguards to each attack-path step
Do not create a checklist detached from the diagram. For every step, record the control owner, implementation status, evidence, detection signal, and residual decision. The following mapping reflects the safeguards highlighted by CISA and NIST:
| Attack-path step | Safeguards to map | Decision or evidence to record |
|---|---|---|
| Credential or social-engineering access | MFA, standard user accounts, secure email and endpoint detection, and phishing-resistant access where supported | Which accounts are exempt, who approves exceptions, and how an alert reaches the responder |
| Privilege escalation | Least privilege, just-in-time privilege, separate administrative accounts, and protected management workstations | Which roles can grant access and how quickly privilege can be revoked |
| Lateral movement | Network segmentation, zero-trust access, restricted east-west administration, and controlled remote access | Which subnets or identities can be isolated without taking down safety-critical functions |
| Exploitation of exposed services | Asset ownership, secure configuration, patch and exposure management, and monitored VPN or remote-access paths | Internet-facing inventory, remediation deadlines, and compensating controls |
| Backup targeting | Offline or isolated backups, immutable storage, separate administration, and protected backup credentials | Who can alter or delete backups and how restoration is verified |
| Encryption and exfiltration | Endpoint, network, identity, and data-loss detection with defined severity thresholds | What evidence is preserved and who authorizes isolation, shutdown, or external notification |
NIST states, “Employ zero trust principles in all networked systems.” Zero trust is a design principle for continuously limiting access; it is not a single product to add to the diagram.
7. Define detection, containment, and communication decisions
Write the decisions responders must make while systems are failing. Specify alert sources, severity thresholds, escalation times, and the authority to isolate an endpoint, identity, subnet, cloud account, or vendor connection. CISA’s checklist begins by determining impacted systems and immediately isolating them; your model should identify who can do that safely and what essential service might be affected.
Recommended Free Tools
Include an evidence-preservation path for volatile logs, memory, endpoint telemetry, identity events, and cloud audit records. Define when legal, privacy, insurers, regulators, law enforcement, customers, and critical suppliers are contacted. List current contacts and provide out-of-band communications—such as a separately administered channel or phone procedure—because normal email and collaboration systems may be unavailable or untrusted.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.8. Turn the model into a recovery design
Rank mission-critical services and document the order in which they can be restored. For each service, identify the recovery owner, clean-room or recovery-network requirement, backup source, dependencies, validation checks, and criteria for reconnecting to production.
NIST states, “Back up data, secure backups, and test restoration.” CISA recommends offline encrypted backups and regular testing. Treat a backup as a recovery capability only after a restoration test demonstrates that it is usable, sufficiently current, and independent enough from the compromised production environment.
Compare recovery designs using the factors that matter to your business:
- Prevention strength and blast-radius reduction.
- Detection speed and the time needed to contain spread.
- Restoration time and restoration-point capability.
- Independence from the production identity plane.
- Operational complexity, vendor dependency, and cost.
Record the trade-off for each critical service rather than selecting one design for the entire company.
9. Exercise and maintain the threat model
Run both discussion-based tabletop exercises and technical restoration or isolation tests. Walk through a stolen administrator credential, a compromised vendor connection, simultaneous encryption, and suspected data theft. Verify that named people can reach one another out of band, exercise their authority, preserve evidence, and make notification decisions.
Review the model after incidents, major architecture or identity changes, acquisitions, new cloud tenants, and vendor changes. Refresh the asset and dependency inventory on a defined schedule. CISA identifies its Ransomware Readiness Assessment, cybersecurity advisors, and exercise packages as evaluation resources that can support this work.
A practical record for each scenario
Keep one concise record per attack path with these fields:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Scenario name, affected service, owner, and last review date.
- Initial access, trust boundaries, privilege steps, lateral-movement routes, and impact.
- Controls at each step, evidence of operation, gaps, and compensating measures.
- Detection signals, severity, isolation authority, evidence custodian, and communication channel.
- Downtime tolerance, recovery order, backup source, restoration test date, and reconnection criteria.
- Decisions requiring executive, legal, privacy, continuity, or communications approval.
Maintained this way, the model becomes a shared decision map for security, IT, continuity, legal, and executives. It shows where investment reduces spread or shortens recovery, while making the remaining business choices explicit.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
