Ransomware preparation is easy to postpone because it sounds like preparation for an unusual event. The work itself is ordinary: know what matters, limit access, maintain systems, and prove that important information can be recovered.
You do not need a frightening scenario to make that work worthwhile. Each part also helps the business handle more common failures and mistakes.
Start with the work you must keep doing
List the processes the business cannot leave unavailable for long. Billing, dispatch, scheduling, and shared records may have different tolerances. Ask the owner of each process what they would need to resume it.
This is your business decision, not a number an IT product can choose for you. A proposed recovery design should explain how it supports those priorities and what remains dependent on another vendor or system.
Protect recovery from the same incident
The joint StopRansomware guidance emphasizes protected backups and testing. An accessible copy can be affected by some of the same problems as live data. Ask how the recovery copies are separated or protected and who can change them.
Keep this technical discussion tied to a practical test. Restore an approved sample into a separate location, open it, and confirm it is usable. Document what was tested and what was not. Do not label a full business recovery verified because one small file restored successfully.
Reduce unnecessary access and exposure
Ask IT to review access, supported software, and security maintenance. Identify accounts and remote-access paths that no longer serve a business purpose. Prioritize the gaps that matter most to critical work.
The goal is not to have the owner toggle unfamiliar settings. It is to give an authorized administrator a clear, reviewed set of improvements and a way to check that the changes did not break necessary operations.
Prepare a decision sheet
Name the incident lead, the IT contact, key providers, and any insurance reporting route required by your policy. Keep an accessible copy outside the systems that might be affected.
Define who can authorize containment, recovery work, and external communications. An employee should not have to decide alone whether to disconnect a shared system or tell customers that records are lost.
Rehearse a short scenario
In a tabletop conversation, suppose the shared files cannot be opened. Ask who receives the report, how the team communicates, what work can continue, and how recovery is approved. Do not alter live systems for the exercise.
A real suspected incident requires the response team. Avoid experimenting with recovery, paying demands, or repeatedly restarting affected machines while waiting for instructions. Preserve useful information and follow the established containment process.
Readiness is not a promise that nothing will happen. It is a set of decisions and tested capabilities that makes a bad day less dependent on guesswork. Start with one critical process and build from there.