How to Test Your SMB's Ransomware Readiness

To scope evidence-based ransomware readiness tests for your environment, contact Quantm Technologies for a conversation.

Readiness-test priorities

A ransomware readiness assessment covers five domains: prevention, detection, backup, response, and human factors
Self-assessment identifies obvious gaps, but professional penetration testing reveals what self-assessment misses
Readiness testing should be conducted quarterly, not annually, given the speed of threat evolution

Readiness requires current evidence

A ransomware readiness assessment closes this gap by systematically evaluating your actual defensive capabilities against the tactics used in real-world attacks. The assessment does not ask what tools you own, it tests whether those tools are properly configured, actively monitored, and effective against current threats.

Test domains and limitations

The five domains of ransomware readiness. A comprehensive readiness assessment evaluates five interconnected domains, each scored independently and then weighted into an overall readiness score.

Frequently Asked Questions

How long does a ransomware readiness assessment take?

The timeline depends on scope, evidence access, number of services, suppliers, and whether technical tests are included. Define the systems, business services, test cases, participants, and required records before accepting a duration estimate.

How much does a ransomware readiness assessment cost?

Cost depends on the same scope and depth. A document review, configuration check, restore test, tabletop exercise, and technical validation are different activities. Ask for deliverables, exclusions, evidence handling, remediation support, and retesting terms in the proposal.

What should we do with the assessment results?

Convert each failed or partial condition into an owned task with an affected service, intended result, accountable person, evidence requirement, due date, and retest. Keep accepted risks and unavailable evidence visible instead of hiding them in an average score.

Test readiness through evidence, not a self-assigned score

A readiness assessment is a collection of reproducible tests. Check identity, exposed services, endpoint coverage, monitored telemetry, backups, response authority, continuity, communications, and supplier access against explicit pass conditions. Keep failed conditions visible even when other areas perform well.

Define scope, owners, and proof

Include leadership, IT, security providers, application owners, continuity, legal counsel, and privacy. Assign one accountable owner and an alternate to each decision. Set the boundary around test scope, pass criteria, evidence, limitations, remediation owners, and retest dates. Record exclusions so leadership can see what the assessment does not prove.

Measure what the exercise establishes

One useful measure for this subject is percentage of agreed test cases passed with current evidence. Pair it with control coverage, age of open exceptions, time to reach decision-makers, restore success, and the percentage of remediation items closed by their due dates. Measures need definitions. For example, “response time” may mean alert acknowledgement, analyst investigation, customer escalation, containment, or full recovery. Those are different clocks.

Source and visual plan

Use test cases instead of a universal score

A readiness result should state what was tested, the evidence reviewed, the pass condition, and the limitation. A single percentage hides differences among critical services. An organization may have strong endpoint coverage but no tested restoration for its order system. Another may have reliable backups but unclear authority to isolate a compromised identity. Treat these as separate findings with different owners.

Write test cases in plain language. For remote access, verify that every current account uses the approved authentication control and that exceptions are owned and dated. For monitoring, generate a benign signal and confirm it reaches the expected queue, receives an investigation record, and follows the escalation path. For backups, restore a representative service and have its business owner confirm data, permissions, and function. For response, run a scenario through both primary and alternate contacts.

Rate each test as passed, partially passed, failed, or not tested. Attach the evidence and date. “Partially passed” needs a description of what worked and what did not. “Not tested” must remain distinct from “passed based on interview.” This gives leadership a defensible view without pretending that a weighted score predicts whether an attack will succeed.

Turn findings into an owned backlog

Each failed or partial test needs a risk statement, remediation owner, target date, required dependency, and retest method. Group related findings so the business can address root causes. Several monitoring gaps may come from an incomplete asset inventory. Multiple recovery failures may point to shared identity or network dependencies. Fixing the common cause can be more effective than closing tickets separately.

Report overdue items and accepted exceptions to the leader who owns the affected business service. Acceptance should record the reason, compensating controls, review date, and authority. Retest completed work using the original pass condition. This closes the assessment loop and creates evidence that the organization's operating capability changed.

Keep prior results so reviewers can distinguish a newly discovered gap from a regression. Trend reporting should compare equivalent tests and disclose changes in scope or evidence quality.

Use pass conditions that can be reproduced

A readiness assessment should say what was tested and what evidence supports the result. A single percentage can hide a failed recovery test behind several policy checks. Separate identity, exposure, monitoring, response, continuity and restoration into test cases with explicit pass conditions.

The readiness assessment owner can begin with one critical service and the identities, devices, logs and backups that support it. The review should include test scope, expected result, current evidence, limitation, remediation owner and retest date. Keeping that boundary visible helps participants distinguish a demonstrated result from an assumption about the wider environment.

Review area	Evidence	Failure to correct
Prevent	MFA, exposed-service and privilege test	Policy exists but coverage is unknown
Detect	Benign signal and complete investigation record	A dashboard screenshot replaces an operating test
Respond	Contact and authority exercise	The primary contact is the only route
Recover	Clean restore with business-owner validation	The assessment checks backup status only

Run a safe validation: repeat a failed case after remediation and compare the result using the same pass condition. Record the expected result, observed result, limitation, owner and retest date. The record is more useful than a generic score because another reviewer can reproduce the check.

Related reading: the prevention control set, a response exercise, restore testing. Each link answers an adjacent question and keeps this article focused on its own intent.

Put reproducible ransomware readiness testing into operation

Begin with one critical service and a small set of pass conditions that another reviewer can repeat. Run the first assessment through these steps:

Define service scope and pass conditions. Name the owner, scope and expected result before changing a control.
Run prevention, detection, response and restore cases. Record exceptions and dependencies instead of treating partial coverage as complete.
Assign remediation and repeat failed tests. Preserve the evidence and assign follow-up work with a retest date.

Evidence to retain

Test case and expected result should show the current scope rather than a planned future state.
Configuration or event evidence should identify the person or system that produced the record.
Limitation and exception record should include the date, limitation and unresolved exception.
Owner and retest result should connect the technical result to the affected business service.

Evidence for readiness-testing ages. Review it after a major platform, supplier, identity, policy or staffing change. If the environment no longer matches the tested scope, mark the prior result as historical and schedule a new check.

Review questions

What was actually tested?
Can another reviewer repeat it?
Which critical service was excluded?
Who accepts an exception?
Did the retest use the same condition?

Keep failed conditions separate and assign each to the owner who can change the affected identity, system, procedure, or supplier agreement. Repeat the original test after remediation. The ransomware protection guide provides context without replacing the detailed evidence register.

Report limitations beside results

A readiness report should state which locations, cloud tenants, suppliers, devices and business services were excluded. It should also identify evidence supplied by interview rather than direct observation. These limits do not invalidate the assessment, but they change what leadership can conclude.

Keep individual test results visible instead of hiding them behind an average. A failed restore for the order system still requires action even when identity and email tests pass. Report improvement by comparing equivalent tests over time and explain any scope change that makes the results difficult to compare.

Leadership should receive the failed conditions, affected services, owners and due dates. Technical detail can remain in the evidence record, but the decision summary must show what business capability is not yet demonstrated.

Retest the weak point, not the whole programme

After the first review, convert each failed or partial condition into a correction with a clear completion test. If privileged accounts lacked strong authentication, retest the affected sign-in paths. If a restore missed an integration, rerun the service transaction after the dependency is corrected. If the incident team could not reach a supplier, verify the updated contact and escalation route from the alternate workspace.

Focused retesting keeps the work manageable and produces evidence that a specific gap was closed. It also prevents a broad annual assessment from masking months of unresolved findings. Keep the original result, remediation record and retest evidence together so a reviewer can follow the change over time. When the environment changes materially, reassess the affected scope and mark older evidence as historical. Readiness is therefore a set of reproducible conditions, not a permanent score awarded after one workshop.

Download the ransomware readiness scorecard

Download the ransomware readiness scorecard as CSV. It provides separate test cases for identity, exposure, detection, response, recovery, and continuity.

Do not average a failed recovery test away with several policy checks. Record Pass, Partial, Fail, or N/A for each condition and retain the evidence, limitation, owner, and retest date. A score can summarize the register for leadership, but the individual failed conditions remain the release gate for the affected service.