The first objective is control, not speed alone
A ransomware discovery creates pressure to act immediately, but uncoordinated actions can spread damage, destroy evidence, alert an intruder, or contaminate backups. The first 24 hours should follow an approved incident-response plan led by authorized decision-makers and qualified responders.
CISA's #StopRansomware Guide says organizations should begin by determining which systems are affected and immediately isolating them. It also cautions that powering down a device can destroy evidence held in volatile memory and should generally be considered when network disconnection is not possible. These are not interchangeable actions.
For a Central Florida medical office, contractor, law firm, school, manufacturer, property manager, or service business, the operational plan must account for customer service, safety, legal and contractual duties, insurance, payroll, vendor access, cloud services, and physical locations—not only encrypted files.
Minutes 0–30: report, verify, and establish command
Treat encryption notes, mass file renaming, inaccessible shared drives, unusual administrator activity, disabled security tools, or widespread endpoint alerts as a potential incident. Employees should stop interacting with the affected device and contact the designated response number using an approved channel.
The incident lead should open a decision log and record the time, reporter, device, location, symptoms, accounts involved, and actions already taken. Use a known telephone number or other out-of-band channel if email or collaboration tools may be monitored by an attacker.
Do not forward suspicious files broadly, contact the attacker casually, post details publicly, or begin deleting files. Do not assume that a single restored document proves the event is contained. Ransomware can be the visible end of an earlier intrusion involving stolen credentials, remote access, data theft, or persistence.
Minutes 30–90: isolate affected systems
Qualified staff should identify affected computers, servers, virtual machines, network segments, cloud resources, storage systems, and accounts. CISA recommends immediately isolating impacted systems. Depending on the environment, that may mean removing network connectivity, isolating an endpoint through a security platform, disabling a switch port, separating a network segment, or restricting a compromised cloud identity.
If several systems or subnets are affected, CISA notes that taking the network offline at the switch level may be necessary. Coordinate this decision because shutting down business systems can affect safety, phones, access control, medical or industrial operations, and evidence collection.
Avoid powering off affected devices unless disconnection is not possible or a qualified responder directs it. Power loss may remove memory-resident evidence that could help identify the ransomware, active sessions, encryption keys, or attacker activity.
At the same time, protect systems that appear unaffected. Keep them logically separated until responders understand the path of compromise. Do not connect portable drives or restored systems to a network that has not been declared clean.
Hours 1–3: activate the response team
Notify the internal incident lead, IT or security provider, executive decision-maker, legal counsel, cyber insurer, and other contacts defined in the response plan. Follow the insurer's notice and vendor-engagement procedures before committing to outside expenses when possible.
CISA recommends reporting ransomware incidents and considering assistance from CISA, the local FBI field office, and the FBI Internet Crime Complaint Center. The IC3 ransomware reporting page lists useful details such as the suspected variant, encrypted-file extension, attacker email or website, cryptocurrency information, ransom amount, and payment status. Preserve these details without exposing them unnecessarily.
Determine whether the event may involve regulated, personal, patient, student, payment, contractual, or customer data. Do not make public statements or breach determinations from incomplete facts. Legal and regulatory obligations vary, and experienced counsel should guide notifications.
Hours 2–6: preserve evidence and scope the incident
Responders may need system images, memory captures, security alerts, firewall and identity logs, cloud audit records, ransom notes, suspicious emails, malware samples, and timestamps. CISA emphasizes preserving evidence that is volatile or subject to short retention.
Record the collection method, time, source, and person responsible. Preserve originals and work from copies when appropriate. Avoid wiping, rebuilding, or resetting every account before responders understand which evidence and access paths matter.
Scope should include:
- Endpoints, servers, network shares, hypervisors, and cloud workloads.
- Email, remote-access, administrator, service, and vendor accounts.
- Backup consoles, repositories, retention policies, and deletion events.
- Security-tool tampering and disabled logging.
- Unusual data transfer or signs of possible exfiltration.
- Newly created accounts, privilege changes, forwarding rules, scheduled tasks, or remote-management tools.
A ransomware note is not proof of which systems or data were accessed. Separate confirmed facts, credible indicators, assumptions, and unanswered questions in the incident log.
Hours 4–12: protect the recovery path
Do not begin broad restoration until the organization has a clean recovery environment, understands the likely entry path, and protects backup administration. Attackers may have stolen credentials or altered recovery systems before encryption began.
Confirm which backup copies are offline, isolated, immutable, or otherwise protected. Preserve the backup state and relevant logs. Test recovery using a representative copy in a segregated environment. NIST recommends secure, isolated backups and regular restoration testing because availability alone does not establish integrity.
Prioritize systems according to a documented critical-services list: health and safety, identity, communications, revenue, customer service, operational technology, finance, and other essential functions. Record dependencies so a restored application is not connected to a compromised identity service or network.
Prepare clean administrator credentials and a controlled method for password resets after affected systems and persistence mechanisms have been addressed. A rapid password reset performed from a compromised device may expose the new credential.
Hours 6–24: decide, communicate, and prepare recovery
Executives should receive scheduled updates based on verified information. Each update should state what is known, what is unknown, business functions affected, actions completed, risks requiring a decision, and the time of the next update. Employees need clear instructions about approved devices, alternate workflows, customer communications, and where to report suspicious activity.
CISA, the FBI, NSA, and MS-ISAC state that they do not recommend paying ransom. Payment does not guarantee decryption, removal of unauthorized access, or non-disclosure of stolen data, and it may create legal or sanctions risks. Any payment discussion should involve law enforcement, legal counsel, the insurer, and authorized executives; it should not be improvised by technical staff.
Recovery planning should define clean-room requirements, rebuild standards, restoration order, validation criteria, monitoring, customer-service contingencies, and who has authority to reconnect each system. Do not declare the incident over merely because files open again.
Evidence the business should retain
By the end of the first day, the incident record should include:
- Detection time and initial symptoms.
- Affected and potentially affected assets and accounts.
- Isolation actions and approvals.
- Preserved logs, images, notes, and collection details.
- Internal, insurer, legal, provider, CISA, and law-enforcement contacts.
- Business services interrupted and approved workarounds.
- Backup state and results of segregated recovery testing.
- Confirmed facts about data access or exfiltration, clearly separated from assumptions.
- Decisions, decision-makers, reasons, and next review times.
- Recovery priorities and criteria for returning systems to service.
Prepare this sequence before an incident
The best time to make the first-day decisions is before ransomware appears. Maintain an offline contact sheet, current asset and dependency map, insurer instructions, system-isolation procedures, legal and law-enforcement contacts, secure communications method, backup test record, recovery priority list, and decision-log template. Exercise the plan with executives and the actual technology provider.
The goal of the first 24 hours is not to solve every technical and legal question. It is to contain harm, preserve options, establish reliable facts, and create a trustworthy path to recovery.
This article is educational and is not legal, regulatory, insurance, law-enforcement, forensic, or incident-response advice. Organizations facing an active incident should use qualified responders and their approved plans.