A ransomware readiness assessment answers one question: if an attacker encrypted your systems tonight, how much would you lose and how fast could you recover? Most assessments answer it with a questionnaire. Someone ticks "backups: yes", "patching: yes", "MFA: yes", and the result is a reassuring number that nobody can trace back to a real machine. A readiness score is only useful if every point in it is measured from live systems, is tied to a stage of the attack, and tells you what to fix next. This guide explains how to build that kind of score, what the stages are, why an untested backup should count as no backup, and what to do in the first week.
Why the usual ransomware readiness assessment produces the wrong number
The typical ransomware risk assessment is a spreadsheet. Someone walks through a control list, asks the owner of each control whether it is in place, and records the answer. The problems are predictable.
The answer is self-reported. The backup administrator says backups run nightly. They do, on the servers that were in scope three years ago. The file servers added since then are not in the job.
The answer is binary. "Patching: in place" hides the workstations that have not checked in for two months.
The answer is static. The assessment is done once a year. Ransomware operators do not wait for the next review cycle.
The result is a number that cannot tell you which machine to touch first.
A score you can act on has three properties. It is measured, not declared. It is broken down by stage, so a weakness in recovery is not hidden by strength in prevention. And every lost point names a concrete thing to fix.
The stages of a ransomware attack, and what each one needs
Ransomware is not one event. It is a chain, and each link has its own controls. Scoring by stage shows where the chain is weakest. CISA's #StopRansomware guide (https://www.cisa.gov/stopransomware/ransomware-guide) organizes its advice the same way, from preparation through response, and is a good public baseline.
Stage 1: Initial access
How does the attacker get in? Phishing, exposed remote services, unpatched edge devices, stolen credentials. The controls here are email security, a way for users to report phishing, external attack surface review, and vulnerability management that prioritizes what is being exploited now rather than the highest CVSS score. Our guide to vulnerability prioritization covers why the ordering matters.
Stage 2: Execution and privilege escalation
Once on a machine, the attacker needs to run tools and gain admin rights. Application control with default deny, no standing local admin, and hardened endpoint settings make this stage expensive. Standing local admin is the single most common gift to a ransomware operator; see just-in-time admin rights for how to end it without stopping work.
Stage 3: Lateral movement and discovery
The attacker moves from the first machine to the domain controllers, the backup server and the file shares. Weak or reused passwords, open ports between workstations, and unmonitored admin tools let this happen quietly. Password policy compliance for every account, including the admin accounts that are usually exempt, belongs in this stage.
Stage 4: Impact
Encryption, and increasingly exfiltration before encryption. Data loss prevention limits what can leave, and classification tells you what was taken when it is time to notify someone.
Stage 5: Recovery
Can you restore? This is the stage that decides whether you pay. Backups must exist for every system that matters, be isolated from the domain the attacker now controls, and have been restored successfully at least once recently. The last part is the one that fails most often.
Why an untested backup does not count
The failure pattern in ransomware recoveries is familiar: the backup job reported success for months, and the restore failed. The catalog was corrupt. The backup server was domain-joined and was encrypted along with everything else. Or the restore worked but took far longer than anyone expected, because nobody had measured how long a full restore takes.
A readiness score should therefore treat backup as three separate questions:
| Question | Evidence that counts | Evidence that does not count |
|---|---|---|
| Does a backup exist for this system? | A backup job that includes this specific host, with a recent successful run | A policy document saying "all servers are backed up" |
| Is it isolated from the attacker? | Offline, immutable, or in a separate credential domain | "The backup server has a strong password" |
| Has it been restored? | A restore test with a date, a system, and a measured duration | "We restore files for users all the time" |
If the third answer is "never" or "more than a year ago", the backup should score as if it did not exist. That is the honest number. The same principle, that a control must be observed rather than declared, is the foundation of IT audit evidence from live data. Ransomware readiness is the sharpest case of it.
What a good ransomware readiness score looks like
A score worth reviewing every week has these properties.
It is computed from the estate, not from a form. The patching score comes from the scanner's current view of every endpoint. The admin-rights score comes from the local administrators group on every machine. The backup score comes from restore test records with dates.
It is weighted by stage. Recovery and privilege escalation deserve more weight than, say, user awareness, because they decide the outcome. A high score driven entirely by prevention controls while recovery sits at zero is a false comfort.
"Not measured" is not a pass. If the assessment cannot see a control, the control gets no credit. The gap is shown as a gap, not quietly skipped.
Every lost point has a next action. A bare stage score is not actionable. The same score followed by "these servers have no restore test in the last twelve months, and the backup server is domain-joined" is.
It moves when you act. Fix the setting, rescan, and watch the number change. If the score only updates when someone edits a spreadsheet, it is a report, not a measurement.
It states its own caveats. A good score says plainly: no restore has been tested, or no backup is recorded for these hosts. The caveats are the part that would otherwise be hidden.
Ransomware preparedness checklist
Each item should be answerable with evidence, not with "yes".
- Every endpoint and server is in the vulnerability scan, and the ones with known-exploited vulnerabilities are listed by name
- Patches are deployed in rings and "installed" is confirmed by a rescan, not by the installer's exit code
- No user account holds standing local admin on workstations; elevation is time-limited or per-application
- Application control is in enforce mode on at least the servers and admin workstations, with a default-deny rule
- Hardening settings (SMBv1 off, macros restricted, LSASS protection, RDP restricted) are checked continuously and re-applied when they drift
- Password policy is enforced on every account, including service and admin accounts, and compliance is measured rather than assumed
- Open ports between workstations and toward backup infrastructure are known and ranked
- The external attack surface (subdomains, exposed ports, expired TLS, known weaknesses) has been scanned in the last month
- Users have a one-click way to report phishing, and a report leads to the whole campaign being removed, not just one message
- Backups cover every system in the recovery plan, and the coverage list is compared against the actual inventory
- At least one backup copy is offline, immutable or in a separate credential domain
- A full restore of a critical system has been tested in the last twelve months, with the duration recorded
- An incident runbook exists that assumes the domain is compromised
- BitLocker recovery keys are escrowed and retrievable
- The readiness score is reviewed on a schedule, and the lowest stage has an owner
After the first pass, work the lowest stage first. Usually that is recovery: schedule one real restore test this week, record how long it took, and find out whether the backup server shares credentials with the domain. Then rescan. If the score did not move, it is not measuring what you changed, and that is a finding too.
How Tracemark does it
Tracemark's Exposure Management product includes a ransomware readiness score by stage. It is delivered by the same agent that runs on every endpoint and the same console as the rest of the platform, so the score reflects what the estate looks like now rather than what someone remembered to write down.
The score is broken down by stage, so a strong prevention posture cannot hide a weak recovery stage. An untested backup does not count toward the score.
The inputs are measured. Vulnerabilities are ranked with "exploited today" above the highest score, and a vulnerability counts as fixed only when a rescan confirms it, not when it is marked done. Open ports are ranked by risk. Hardening fixes risky settings in one press and re-fixes them when they drift. Password policy compliance is checked for every account, including admins. The external web scan covers subdomains, ports, TLS and known weaknesses on your public surface.
The surrounding products feed the same picture. Application control with default deny, time-limited access requests approved from the console, and running one named application elevated without local admin close the execution stage. Patch management in rings counts "installed" only after a rescan. BitLocker recovery-key escrow with audited retrieval keeps your own encryption from blocking recovery. The Report button in Outlook purges a phishing campaign from every mailbox. Because the controls are measured from live data, the evidence can be sealed into a pack the auditor can open.
Frequently asked questions
How often should we run a ransomware readiness assessment?
Continuously, if the inputs are measured automatically. If you rely on a manual review, at least quarterly, and after any major change such as a new backup platform or a new remote access service. A useful rhythm is a weekly look at the score and a monthly review of the lowest stage.
Is a readiness score the same as a ransomware risk assessment?
They overlap. A risk assessment usually estimates likelihood and impact for the business. A readiness score measures the state of specific controls on specific systems. You need the readiness score to make the risk assessment honest, because the likelihood estimate depends on whether the controls actually work.
What is the single most important control?
A tested, isolated backup. It is the one control that works even when everything else has failed. Second is removing standing admin rights, because that is what turns one infected laptop into a domain-wide event.
Can a small IT team do this without dedicated security staff?
Yes, if the measurement is automated. What overwhelms small teams is collecting evidence by hand. When patch state, hardening settings and port exposure are collected automatically, a two-person team can spend its time fixing the lowest stage.
Try it
Try Tracemark free for three months. Claim it at tracemark.ca