A ransomware incident is a time-sensitive business crisis, but the first response does not have to be improvised. This reusable first-day checklist helps a small business contain the event, preserve useful evidence, communicate carefully, assess backups, and restore operations in a controlled order.
Overview
Ransomware may encrypt files, disrupt systems, steal data, or combine all three. A ransom note or locked computer is only one possible sign. Other indicators include widespread file-name changes, unusual login activity, disabled security tools, inaccessible shared drives, unexpected administrator accounts, or a sudden inability to use core applications.
The first objective is not to remove every trace of the malware immediately. It is to stop the incident from spreading while keeping enough information to understand what happened. A small business should designate one incident lead, one technical decision-maker, and one person responsible for internal communications. If those roles are not already assigned, the owner or senior manager should name them and record their contact details.
Use this order of priorities:
- Protect people and safety. If systems control physical equipment, building access, medical devices, or other safety-critical processes, follow the relevant emergency procedures first.
- Contain the spread. Separate affected devices and accounts from the business network.
- Preserve evidence. Record what was observed before wiping, rebuilding, or changing systems.
- Protect essential operations. Move to approved manual or alternate processes where possible.
- Plan recovery. Validate backups and rebuild in a deliberate sequence rather than reconnecting everything at once.
Do not treat a ransom demand as proof that paying will restore access or prevent disclosure. Payment decisions involve legal, financial, operational, and ethical considerations and should be reviewed by qualified advisers. Never assume that a decryption tool, a promise of deletion, or a short deadline makes the decision safe.
Checklist by scenario
When one computer appears infected
- Disconnect the device from wired and wireless networks. If it is safe to do so, unplug the network cable or disable Wi-Fi; do not shut down a device automatically if your technical adviser needs volatile evidence.
- Do not open files, run unknown cleanup tools, or connect removable media to the device.
- Record the device name, user, location, time of discovery, visible message, and any unusual activity.
- Check whether the same user account was active on other devices. Revoke sessions or disable the account if compromise is suspected, using a clean administrator device.
- Look for related signs on shared drives, cloud storage, email, and remote-access systems.
When multiple systems or shared drives are affected
- Activate the incident plan and establish a single decision log. Include time, action, person responsible, and result.
- Isolate affected network segments, servers, virtual machines, and remote-access paths. Avoid making broad changes without recording what changed.
- Pause automated synchronization where it could copy encrypted or deleted files into clean systems or cloud repositories.
- Disable suspected compromised accounts and active remote sessions. Prioritize administrator, backup, email, VPN, and remote-management accounts.
- Protect backup systems from further access. Do not connect backup storage to a potentially compromised network until its integrity and access controls are reviewed.
- Move critical operations to a documented manual process if one exists. Tell staff which systems are unavailable and which channels are approved for updates.
When data theft is suspected
- Preserve ransom notes, unusual outbound traffic records, access logs, alerts, and messages from the attacker.
- List the data and systems that may have been accessed, including customer, employee, payment, health, or confidential business information.
- Do not contact customers, regulators, insurers, or the attacker with an unverified account of events. First establish what is known, what is suspected, and what remains unknown.
- Review notification and contractual obligations with appropriate legal counsel and relevant insurers. Requirements vary by location, industry, data type, and agreement.
- Use an approved communication channel for employees. Remind them not to forward ransom notes or incident details to personal accounts or social media.
When backups appear available
- Do not assume a backup is usable because it completed successfully. Check whether it predates the compromise and whether restoration data is complete.
- Confirm that backup credentials and management consoles were not accessed by the attacker.
- Restore a small, representative set of files or a test system in an isolated environment first.
- Prioritize identity services, network controls, essential applications, and clean workstations before reconnecting general file shares.
- Change exposed credentials and verify multifactor authentication before restored systems return to production.
For broader preparation, pair this checklist with an account and security alert triage process. If suspicious messages or links may have started the incident, review guidance on checking email, text, and QR-code phishing scams.
What to double-check
Isolation: Confirm that affected devices cannot communicate through overlooked paths such as guest networks, remote-access tools, cellular hotspots, cloud synchronization, or shared administrator credentials.
Evidence: Preserve timestamps, screenshots, ransom notes, relevant logs, suspicious email headers, endpoint alerts, firewall records, and a list of actions taken. Keep original copies where possible. Note any gaps caused by unavailable systems or expired logs.
Identity: Review privileged accounts, service accounts, email forwarding rules, newly created users, authentication methods, and active sessions. Check for changes to recovery email addresses and phone numbers.
Backups: Check offline or otherwise isolated copies, retention periods, restoration credentials, and the last known clean restore point. Test the restored data before relying on it for business operations.
Communication: Use plain language and avoid speculation. A useful internal update states what is unavailable, what employees must not do, where to report observations, and when the next update is expected. Do not ask staff to investigate attackers independently.
External obligations: Review cyber insurance requirements, customer contracts, payment-provider rules, employment obligations, and applicable breach-notification requirements. Record who made each decision and why.
Common mistakes
- Wiping every affected device immediately. Rebuilding may be necessary, but doing so before collecting basic evidence can make the entry point and scope harder to determine.
- Reconnecting systems as soon as files become available. A partially restored environment can be reinfected if compromised accounts, tools, or persistence mechanisms remain.
- Trusting the attacker’s claims. Treat statements about deletion, deadlines, or stolen data as unverified. Preserve the demand without clicking links or opening attachments.
- Using an affected email account for incident coordination. Establish a clean channel, and protect it with strong authentication.
- Restoring only the visible files. Identity systems, configurations, software installers, access rules, and business records may be equally important to a safe recovery.
- Ignoring phones and personal devices. Employees may use them for email, authentication, file access, or remote administration. Review those access paths without collecting more personal information than necessary.
- Keeping the incident plan in the affected network. Store a current offline or separately accessible copy of contacts, recovery steps, vendor details, and system dependencies.
When to revisit
Review this ransomware response plan before seasonal planning cycles, after major changes to software or workflows, and whenever the business adds cloud services, remote-access tools, locations, or critical suppliers. Revisit it after an incident, near miss, phishing event, backup failure, or change in insurance or contractual obligations.
At least once a year, run a short tabletop exercise. Give participants a realistic scenario, such as an encrypted file server combined with a locked administrator account, and ask them to identify the first call, the clean communication channel, the recovery priority, and the evidence they would preserve. Test whether someone can retrieve the offline plan and whether backups can be restored without production access.
Before filing the plan away, update the following:
- Incident-lead and alternate contacts
- Critical systems and their dependencies
- Backup locations, retention, and restore instructions
- Approved emergency communication channels
- Cloud, hosting, payment, and technology-provider contacts
- Legal, insurance, and notification escalation steps
- Instructions for disabling remote access and privileged accounts
The best ransomware response plan is short enough to use under pressure and specific enough to prevent guesswork. Print the first-day checklist, keep a separate digital copy, assign owners to each action, and test the recovery path before an alert turns into an outage.
