Ransomware readiness is not a single product purchase. It is the ability to prevent a compromise, detect it early, contain affected systems and restore important operations. A focused 30-day assessment helps an organisation find practical gaps without waiting for a crisis.
Days 1–5: establish ownership and exposure
Name an incident lead and confirm emergency contacts. Inventory internet-facing assets, remote access, identity providers, critical applications, backups and key suppliers. Identify unsupported systems and accounts with administrative access. Record what the business must restore first.
Days 6–10: protect identities
Enforce phishing-resistant MFA for privileged users, remove legacy authentication and review recovery processes. Disable dormant accounts, reduce standing privilege and protect backup identities separately. Check OAuth applications and forwarding rules for unexpected access.
Days 11–15: harden endpoints and servers
Confirm patching, endpoint detection, local administrator controls, macro policies and application allowlists. Segment critical systems and restrict remote administration. Verify that logs reach a protected central location and cannot be deleted by ordinary administrators.
Days 16–20: validate backups and recovery
Test restore from offline or immutable backups. Measure how long a clean recovery takes and whether applications depend on unavailable secrets or network services. Document recovery order, owners and a decision process for isolating systems.
Days 21–25: test detection and response
Run a tabletop exercise using an approved scenario. Confirm who can disable accounts, isolate endpoints, contact suppliers, preserve evidence and communicate with customers. Review alert coverage for mass encryption, unusual identity activity and bulk data access.
Days 26–30: independent validation
Commission authorised vulnerability scanning, penetration testing or configuration review. Prioritise weaknesses that enable initial access, privilege escalation, backup destruction or data theft. Re-test critical fixes and publish a dated remediation plan.
Detox’s cyber security services can support VAPT and readiness validation. Link to the common cyber threats article for related reader guidance.
Evidence to collect during the assessment
A readiness review should produce more than a green checklist. Collect evidence that shows whether controls work and whether people can operate them during an incident. The following items turn the 30-day plan into a repeatable assessment with clear ownership.
1. Critical-service list
During review, agree which services, data and dependencies must be restored first. Keep evidence that technical recovery order matches business priorities. This prevents a policy statement from being mistaken for a working control and gives the remediation owner a clear acceptance test.
2. External attack surface
A practical test should verify domains, IP addresses, VPNs, gateways and remote management. The expected result is that unknown or unsupported exposure enters remediation. Record exceptions with an owner and expiry date; undocumented exceptions tend to become permanent exposure.
3. Privileged accounts
Ask the responsible team to review human, emergency, service and vendor administrators. Validate the answer in a representative environment so that every powerful identity has an owner and justified access. Where the control fails, capture business impact as well as the technical weakness.
4. MFA coverage
For this area, test enrolment, recovery, exclusions and legacy authentication. Reviewers should be able to demonstrate that high-risk applications cannot fall back to weak login. Re-test after material architecture or supplier changes because the effective boundary may have moved.
5. Endpoint coverage
The control objective is straightforward: compare active assets with EDR and patch-management consoles. Evidence should show that unmanaged systems are found instead of assumed protected. If several teams share responsibility, name one person who coordinates the final decision and follow-up.
6. Network segmentation
Do not rely only on documentation; test paths between user, server, backup and management zones. A successful check confirms that one compromised endpoint has a limited blast radius. Include negative tests, since secure behaviour is often revealed by how the system rejects an invalid or unauthorised request.
7. Backup isolation
During review, review deletion rights, immutability, offline copies and alerting. Keep evidence that production compromise cannot silently remove every recovery point. This prevents a policy statement from being mistaken for a working control and gives the remediation owner a clear acceptance test.
8. Restore proof
A practical test should recover representative applications and data into a clean environment. The expected result is that recovery time and missing dependencies are measured. Record exceptions with an owner and expiry date; undocumented exceptions tend to become permanent exposure.
9. Log resilience
Ask the responsible team to confirm identity, endpoint, cloud and backup logs reach protected storage. Validate the answer in a representative environment so that attackers cannot erase the complete investigation trail. Where the control fails, capture business impact as well as the technical weakness.
10. Detection exercise
For this area, simulate account takeover, bulk access and security-control changes. Reviewers should be able to demonstrate that alerts reach a responder with useful context. Re-test after material architecture or supplier changes because the effective boundary may have moved.
11. Containment authority
The control objective is straightforward: name people who can isolate systems, revoke tokens and block suppliers. Evidence should show that urgent actions do not wait for unclear approval. If several teams share responsibility, name one person who coordinates the final decision and follow-up.
12. Communication plan
Do not rely only on documentation; prepare internal, customer, regulatory and vendor contact paths. A successful check confirms that messages can be accurate even when normal systems are unavailable. Include negative tests, since secure behaviour is often revealed by how the system rejects an invalid or unauthorised request.
13. Evidence handling
During review, document preservation, timestamps and chain-of-custody expectations. Keep evidence that response actions do not destroy information needed later. This prevents a policy statement from being mistaken for a working control and gives the remediation owner a clear acceptance test.
14. Tabletop exercise
A practical test should walk leaders and technical teams through a realistic scenario. The expected result is that decisions, dependencies and gaps become assigned actions. Record exceptions with an owner and expiry date; undocumented exceptions tend to become permanent exposure.
15. Retest
Ask the responsible team to repeat critical findings after remediation and record residual risk. Validate the answer in a representative environment so that the programme demonstrates improvement rather than activity. Where the control fails, capture business impact as well as the technical weakness.
Taken together, these checks create a defensible baseline. Prioritise findings that enable unauthorised access, sensitive-data exposure, irreversible action or loss of recovery capability. Assign dates, validate fixes and keep the evidence with the system’s security record.
What a successful month produces
At the end of 30 days, the organisation should have a verified asset and identity list, named incident roles, prioritised remediation, tested backup restoration and evidence from at least one exercise. It should also know what remains uncertain. A mature outcome is not a claim that ransomware is impossible; it is a clearer view of exposure and a rehearsed ability to contain and recover.
A realistic tabletop scenario
Begin with a user reporting repeated MFA prompts. An endpoint alert then shows an unfamiliar remote tool, while the backup team sees an attempted retention change. Ask participants to decide what to isolate, which sessions to revoke, whether to disconnect systems and how to preserve evidence. Introduce a claimed data leak and a supplier outage. The facilitator should capture decisions, missing information and hand-off delays rather than trying to trick participants.
Prioritising remediation
Fix paths that combine initial access, privilege and recovery impact. An exposed remote service with weak authentication may deserve attention before dozens of low-risk workstation findings. Protect identity and backups early because they influence containment and restoration across the environment. Assign every critical action an owner, deadline and acceptance test. Where a fix must wait, document a temporary control and expiry date.
Keeping readiness current
Repeat external exposure checks and identity reviews regularly. Test a different application restore each quarter and update contacts after organisational changes. Re-run tabletop exercises with new scenarios and include suppliers that operate critical services. Review lessons from real alerts, even when they were false positives. Readiness decays when documentation, credentials and architecture change without practice.
Board-level reporting
Leadership needs a short account of critical exposure, recovery confidence, unresolved risk and investment decisions. Report tested restoration times, privileged-access coverage and overdue critical actions. Avoid dashboards filled only with scan counts. The central question is whether the organisation can keep priority services safe or restore them within an acceptable period after a serious identity or endpoint compromise.
After day 30
First quarter
Close critical identity and exposure findings, complete at least one application restore and verify protected logging. Report overdue risks to accountable leaders. The responsible team should retain configuration evidence, test results, named exceptions and a completion date. Before moving to the next stage, confirm that the control works in practice and that operational teams know how to support it.
Second quarter
Expand segmentation and privileged-access improvements, test supplier contacts and conduct a different recovery exercise. The responsible team should retain configuration evidence, test results, named exceptions and a completion date. Before moving to the next stage, confirm that the control works in practice and that operational teams know how to support it.
Third quarter
Review service accounts, cloud tokens and unsupported assets. Repeat external attack-surface validation and update the incident scenario. The responsible team should retain configuration evidence, test results, named exceptions and a completion date. Before moving to the next stage, confirm that the control works in practice and that operational teams know how to support it.
Fourth quarter
Run an organisation-wide tabletop, compare recovery results with business targets and fund the next cycle based on evidence. The responsible team should retain configuration evidence, test results, named exceptions and a completion date. Before moving to the next stage, confirm that the control works in practice and that operational teams know how to support it.
A roadmap is useful because it creates order, not because every organisation must follow identical dates. Adjust sequencing for business impact, dependencies and available expertise, while keeping ownership and verification explicit.
Choosing an independent assessment scope
Focus external testing on the paths that could affect identity, critical data and recovery. Provide clear rules of engagement, test accounts and emergency contacts. The assessment should end with reproducible findings, business impact, remediation guidance and validation of critical fixes.
Include cloud control planes, remote access, backup administration and exposed applications. Scanning alone is insufficient where identity, authorization and recovery workflows determine impact.
FAQ
For deeper coverage of account takeover and privilege abuse, read the identity-based ransomware prevention guide.
Is paying for recovery part of readiness?
Readiness means having options: prevention, containment, clean restoration, legal advice and communications. Payment decisions require executive, legal and law-enforcement input.
What is the biggest backup mistake?
Assuming a backup is usable without performing a restore test under realistic conditions.
How often should the checklist repeat?
Review continuously, run a formal exercise at least annually and reassess after major infrastructure or identity changes.
Conclusion
A 30-day programme cannot remove every risk, but it can expose the gaps that determine whether ransomware becomes an outage or a contained incident. Start with identity, backups and recovery, then validate controls through testing.
Keep the resulting action register visible to technology and business owners. Close critical items, test the fix and carry unresolved risks into the next exercise. Readiness comes from repeated evidence, not the age of the incident-response document.
