The ransomware basics are backups you have tested restoring, multi-factor authentication on remote access and admin accounts, quick patching of vulnerabilities attackers are already exploiting, and a response plan someone has rehearsed. CISA's StopRansomware guide builds its advice around these, and most incidents trace back to one of them being missing.
Why do the basics matter more than new tools?
Ransomware crews do not need novel techniques when a remote desktop port is open, an old VPN appliance is unpatched or one admin password was reused. Each missing basic shortens the attacker's path from first access to encrypting servers.
New products can help, but they sit on top of the foundation. If your backups are online and writable from the domain, a clever detection tool will only tell you faster that they are gone.
Which basics have the biggest effect?
Think in the order an incident unfolds: get in, spread, encrypt, demand.
Getting in. Stolen or guessed credentials, exposed remote access, phishing and unpatched internet-facing systems. Controls: MFA everywhere it can be turned on, no direct remote desktop from the internet, an inventory of what is exposed, and patching the flaws on CISA's Known Exploited Vulnerabilities catalog first.
Spreading. Flat networks and shared admin passwords turn one laptop into the whole company. Controls: unique local admin passwords, separate admin accounts, and segmentation between user networks and servers.
Encrypting. Attackers often try to delete or encrypt backups first. Controls: offline or immutable copies, and a restore test you have actually run.
Demanding. Data theft before encryption means restoring from backup does not end the problem. Controls: know what sensitive data you hold and where, and decide in advance who talks to regulators, customers and law enforcement.
What does a failed restore look like?
A constructed example. A company runs nightly backups to a network share that every domain admin can write to. An attacker with a domain admin account encrypts production and then the share. The backup software reports success every night, but nobody has restored a full system in two years, so nobody knows how long recovery takes or whether the catalog is intact.
Compare a team that restores one critical system every quarter from an immutable copy, times it and writes down the order of recovery. On the bad day they are following a runbook, not improvising.
How fast should you patch?
Prioritise by exploitation, not only by severity score. A flaw listed in the KEV catalog has evidence of exploitation in the wild, so it jumps the queue. CISA's directive BOD 22-01 sets deadlines for federal agencies, and many private teams borrow the same list as a priority signal.
For software dependencies, the question is also whether your code reaches the vulnerable function. Reachability analysis helps you separate a flaw that matters from one that only appears in a scan report. Safeguard offers reachability analysis and a free in-browser dependency scan at gold.safeguard.sh/scan for up to 100 dependencies.
How do you know you are improving?
Pick three numbers and track them monthly: the share of remote access paths covered by multi-factor authentication, the median days to fix an exploited vulnerability on an internet-facing system, and the time of your last full restore test. Numbers like these show leadership whether the basics are real. They also reveal quickly when a team has drifted, for example when a new remote tool is installed without MFA, or when backups quietly stop completing. Review them with the same regularity as financial results, and treat a missed restore test as an incident in the making.
How to check or apply this
- List every internet-facing service and remove or protect remote access that lacks MFA.
- Subscribe to the KEV catalog and set an internal deadline for items that apply to you.
- Make backups immutable or offline, and restore one important system this quarter. Record the time.
- Remove shared local admin passwords and split daily and admin accounts.
- Write a one-page response plan with contact numbers, decision owners and legal contacts, and rehearse it once.
- Know where regulated and sensitive data lives, because extortion can happen without encryption.
Quick check
Does a good backup mean I can ignore ransomware?
No. Backups help you recover, but attackers may also steal data and threaten to publish it. You still need prevention, detection and a communications plan.
What should I patch first?
Internet-facing systems and anything on the KEV catalog, because those have known exploitation.
Sources
- StopRansomware Guide, CISA
- Known Exploited Vulnerabilities Catalog, CISA
- BOD 22-01, CISA
- CIS Controls Implementation Groups, CIS
Last reviewed: 18 October 2026.
