Ransomware preparation starts with a business question: what would stop if your people could not use their normal systems tomorrow? The answer determines which access paths need attention, which data must be recoverable and which decisions cannot wait for the usual approval meeting. Buying another security product may help, but it does not answer those questions.
This guide is for leaders planning improvements before an incident. It covers a practical review of business dependencies, recovery evidence and decision ownership. For an active incident, activate your established response arrangements and obtain appropriately qualified assistance through your agreed channels.
Start with the work the business must keep doing
Choose a small set of essential services and describe their tolerable interruption in operational terms. For a distributor, the concern may be dispatching confirmed orders before the carrier leaves. For a professional-services firm, it may be accessing current client instructions and communicating through a trusted channel. Avoid a single recovery target copied across systems with very different consequences.
Map the dependencies behind each service: identity, devices, connectivity, applications, external providers, data and the people authorised to restore them. Include less obvious items such as licence keys, recovery credentials and the ability to contact a supplier without corporate email. Give each dependency an owner who can demonstrate its present condition.
The output should be a short service recovery map and a list of unresolved assumptions. A statement that a cloud provider handles everything is an assumption until the team knows which tenant settings, copies of data and restoration tasks remain its responsibility.
Reduce exposed access and limit the reach of a compromised account
Review internet-facing services, remote administration, privileged identities and the process used to grant supplier access. Remove access that has no current purpose. Prioritise exploitable exposure and unsupported technology, with an owner and a practical treatment plan for anything that cannot be fixed immediately.
CISA’s #StopRansomware Guide recommends phishing-resistant multifactor authentication, particularly for important access paths, and timely remediation of exposed weaknesses. Translate that advice into a coverage check: which accounts and interfaces actually enforce the intended protection, and where can it be bypassed? An enrolment list alone does not show enforcement.
Also examine what a compromised user could reach. Separate administrative work from everyday email, restrict unnecessary permissions and test the boundaries between business systems and recovery administration. Review exceptions after acquisitions, rushed deployments and supplier changes; these are common moments when the documented access model stops describing reality.
Test restoration as a business process
A successful backup job is evidence that a job completed. It does not establish that the business can recover a usable service. Select a representative restoration exercise that includes data, application configuration, dependencies and the person who can confirm the result is fit for use.
CISA recommends offline, encrypted backups and regular restoration testing. Your design should also address who can alter or delete recovery copies and whether those permissions share the same failure path as production. Where a storage feature is described as immutable, verify its actual configuration and retention behaviour instead of relying on the product label.
Hypothetical example: a small distributor restores its order database in a test environment but discovers that the shipping integration requires a credential stored only on an unavailable administrator’s laptop. The team adds controlled recovery access, documents the integration sequence and repeats the relevant test. The useful result is the removed dependency, not a declaration that every possible incident has been solved.
Agree the decisions that an incident will force
Name who can authorise isolation, suspend a service, approve emergency expenditure and decide when restoration is safe. Establish deputies and a communication route that remains usable when the primary collaboration platform is unavailable. Keep the contact information accessible through an appropriately protected alternative.
Arrange specialist support, insurance notification procedures and relevant legal advice before they are needed. Review the actual policy and contract conditions; do not assume an insurance policy covers every response cost or payment decision. Decisions involving a ransom demand need appropriate legal, financial and investigative input and do not belong to a pre-approved promise to pay.
Record facts separately from assumptions as events develop. Restoration does not resolve whether information was accessed or removed. Assign responsibility for assessing reporting and notification obligations from the applicable law, contract and incident facts rather than treating restored operations as the end of the response.
Exercise a difficult handover
Use a short scenario that crosses technical and business responsibilities. For example, ask the service owner to respond when customer support is unavailable, the usual identity service is under investigation and a supplier cannot yet confirm its own status. Let participants work from the records and contacts they would actually have.
The exercise should expose decisions, not reward participants for reciting the plan. Capture who needs what information, how conflicting priorities will be resolved and which authority is missing. NIST SP 800-61 Revision 3 places incident response within broader cybersecurity risk management; preparation and improvement extend beyond the moment an alert arrives.
Convert findings into funded actions with completion evidence. A contact-list gap may close through a verified call. A recovery dependency may require another technical test. A disputed business priority needs an authorised decision. Assigning a due date without defining acceptable evidence leaves the weakness open.
Give leadership evidence it can act on
Review a small number of meaningful measures: essential services with tested recovery paths, critical access exceptions awaiting treatment, unresolved exercise decisions and restoration tests that failed their agreed objectives. Show the age, owner and consequence of each material gap.
Avoid a dashboard that reports only installed tools, completed training and backup success rates. Those measures may be useful, but they need to connect to exposure and recovery. Ask what changed since the previous review and which assumption has been tested rather than merely repeated.
For structured preparation, our incident-readiness exercises can help define the scenario and decision agenda for an agreed engagement. Organisations using an ISMS can also use our incident and continuity guide to connect lessons with ongoing management review.
Reference basis
- CISA and partner agencies, #StopRansomware Guide (2023).
- NIST SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management (2025).
Questions and answers
Will backups prevent a ransomware incident?
No. Recovery copies can support restoration, but they do not prevent compromised accounts, data theft or disruption. Assess protection, detection, response and recovery together, and test whether the copies can restore the service you actually need.
How often should the business test recovery?
Set a schedule from service criticality, change and the consequences of failure. Also test after material changes to architecture, suppliers or recovery arrangements. A universal interval is less useful than an agreed programme with evidence that important dependencies have been exercised.
Is cloud storage automatically a separate backup?
No. Establish what the service retains, who can delete it, how recovery works and which failure paths affect both the original and its copies. Test your tenant configuration and contractual responsibilities rather than relying on the cloud label.
What should a first tabletop exercise cover?
Choose one essential service and an uncomfortable dependency, such as unavailable identity or email. Test decisions, authorisation, communications and recovery priorities, then assign actions for the gaps exposed.
Can a readiness review guarantee that attacks will not succeed?
No. A review can identify weaknesses and improve preparation within its scope. Decisions, implementation and maintenance still matter, and changing threats or untested conditions can create additional risk.
Make the next recovery decision easier
Bring one essential service, its recovery assumptions and your unresolved incident decisions to a readiness discussion. Discuss a scoped preparation engagement with CyberVantage360.