Ransomware Hits Monday Morning. Who Keeps the Business Moving?

Executive summary

Monday at eight, the order system will not open. Several employees see unfamiliar messages. The shipping coordinator cannot retrieve the day's paperwork, and the office manager cannot tell whether payroll is available.

The immediate problem is technical. The next several problems belong to the business.

Who can interrupt operations? Who calls the IT provider when company email is unavailable? Which job must resume first? Who decides whether a temporary workaround is safe? An owner who discovers those answers during an incident pays for that confusion in time, interrupted work, and rushed decisions.

The companion video runs a fictional 20-person company through two versions of the same ransomware event. It is an illustration, not a client case study or a forecast of your losses. This article turns that contrast into a preparation exercise you can run with the people responsible for operations and technology.

If an incident is happening now, activate qualified response support and open the Small Business Cyber Incident First Actions guide. Protect people first. Contact the financial institution immediately if money may have moved. Do not wait for a consultation appointment to make emergency, bank, insurer, legal, or law-enforcement calls.

The first delay often has no error code

In the unprepared version of the exercise, everyone starts doing something reasonable in isolation.

An employee restarts a workstation. The office manager searches email for the provider's contact. A supervisor asks whether staff should switch to personal laptops. The owner tells the provider to get everything running, without agreeing what everything means or who can authorize the necessary interruption.

None of those people intends to make the incident worse. They lack a shared operating arrangement.

Rehearse that moment before discussing products. Ask each person what they would actually do and where they would obtain the information to do it. "Call IT" is incomplete when the only number sits inside the inaccessible ticketing portal. "Restore the backup" is incomplete when nobody knows who can approve the work or unlock the backup service.

Stop at the first unsupported answer. Record the assumption, the person who can verify it, and the evidence you need. Do not reward confident guesses. A short exercise that exposes one real dependency has more value than an elaborate scenario everyone talks through without checking anything.

Give coordination to one person without making them the technician

Name an incident coordinator and an alternate. Their job is to keep the response coherent: maintain the decision record, connect the right people, and make sure the next update actually happens.

The owner or designated leader retains business decisions such as emergency spending and operational priorities. A qualified technical lead directs containment and investigation. Operations identifies what stops, what remains safe, and which dependencies matter. One person may hold several roles in a small firm, but the responsibilities should not disappear into "we all handle it."

Put the delegation in a short written record. Identify who can authorize urgent work, who can approve a service interruption, and whom the provider calls if the usual owner cannot answer. Agree the practical limits with the provider before an incident.

Preparation belongs in normal risk management, not in a document that appears only after a detection. NIST SP 800-61 Revision 3, published April 3, 2025, places incident response within that broader preparation and management work. You do not need an enterprise command structure to apply the distinction between making a decision and performing the technical task.

Preserve a communication path outside the suspected environment

Company email and chat may be unavailable or untrustworthy during an incident. Keep current response contacts accessible through an approved alternative, with a protected offline copy where appropriate.

A phone tree is only useful if the numbers work and people recognize the caller. Agree how staff verify unexpected instructions, particularly requests to install software, change account access, or move money. An urgent voice on a new number should not acquire authority simply because the company is already under pressure.

During the exercise, have the coordinator locate the provider, leadership alternate, insurer incident contact, and legal contact without opening company email. Do not send real incident alerts as a rehearsal; arrange test calls in advance.

Record an update time even when the answer is still incomplete. "Next operational update at 10:30" gives employees something concrete. Without it, the technical lead fields the same status question from five people while trying to investigate.

Separate an internal working discussion from a customer statement. Staff need instructions; customers need accurate information about their service. Neither needs unsupported speculation about who caused the incident or whether information escaped.

Containment is not permission to improvise across the plant

Limit active spread while preserving safety and useful evidence. For a clearly affected ordinary workstation, network isolation differs from wiping or reinstalling it. In a manufacturing environment, disconnecting equipment can affect physical processes and requires the responsible operational personnel.

The joint StopRansomware response guide distinguishes isolating affected systems from powering them down. It treats powerdown as a fallback when disconnection cannot stop spread, acknowledging the loss of volatile evidence. It also recommends communication outside potentially monitored systems.

Do not turn that into a blanket instruction to pull every cable. Ask your technical provider and operations lead to agree which staff may take which immediate actions, and which systems require specialist involvement. Record the escalation route for uncertainty.

During a real event, do not connect backup media, run random cleanup tools, or broadly reset systems to make an error disappear. Let the authorized response team direct recovery and evidence handling. A cleaner screen does not establish a contained incident.

Restore a business task, not a server-shaped checkbox

"The backup completed" answers a narrower question than "we can ship today's orders."

Take the shipping task in the fictional company. It may require a current order list, approved drawings, inventory status, a label service, a carrier account, employee access, and a working printer. Restoring one database does not necessarily restore that chain.

Ask the operations lead to define the smallest usable version of the task. Ask the technical lead to identify what it depends on and how to validate it in an appropriately isolated recovery environment. Do not reconnect restored systems to a suspected environment merely to see whether they work.

The NIST National Cybersecurity Center of Excellence recovery project distinguishes usable recovery from recovering data whose accuracy or integrity remains uncertain. Apply that idea to the transaction, not only the file.

For the exercise, an acceptance check might be: the authorized shipping coordinator can retrieve an approved test order, verify its revision and quantity, prepare its paperwork, and reconcile the result without changing a live customer shipment. The business owner and technical lead should agree the safe test and its limits in advance.

That evidence still covers only the tested task. Do not describe it as proof that every system will recover on schedule.

Temporary work needs a stopping rule

Paper forms and alternate devices can preserve useful work. They can also create duplicate payments, missing records, exposed customer information, and an expensive reconciliation problem.

Define the permitted workaround before an emergency. For each critical task, record who authorizes it, which information it may use, how staff protect the records, and what prevents duplicate processing when systems return.

In the fictional shipping example, an approved temporary log could identify the order, verified revision, quantity, approving employee, and completion status. The team would also need a rule for orders it cannot verify. "We cannot establish the current drawing" is a reason to stop that job, not a reason to use whatever copy someone finds on a personal laptop.

Name the person who reconciles temporary records afterward. Otherwise, restoring technology simply starts a second phase of uncertainty: which orders shipped, which invoices went out, and which changes never reached the restored system?

A workable limit beats an unrestricted instruction to keep busy. Some operations should pause until the business can verify safety, authorization, or data quality.

Keep the facts, decisions, and obligations separate

An incident record should distinguish an observation from an assumption. "Three employees cannot open files" is an observation. "Only those three computers are affected" requires investigation.

Record the time, source, action, decision-maker, and next check. Preserve relevant messages and records through the response team's process. Do not paste customer data, credentials, or suspected malicious files into an open group chat to get opinions.

The FTC's breach-response guidance addresses evidence preservation, specialist support, communications, and identifying notification requirements. Those requirements depend on the facts, data, jurisdictions, and applicable agreements. This article does not establish a universal reporting deadline or provide legal advice.

Contact the insurer through its incident channel and confirm any required provider or approval process. Do not assume a policy automatically pays for whichever work someone orders. Keep the technical record and cost record organized while counsel and the insurer address their respective responsibilities.

Reporting is another specific task. The FBI's ransomware guidance directs victims to a local field office or the Internet Crime Complaint Center. Its position does not support paying ransom, and payment does not guarantee recovery. Keep that decision with qualified legal, incident-response, and appropriate official support rather than negotiating impulsively.

IC3's reporting page identifies useful complaint details, including known demand and attacker-contact information. Preserve those facts safely; do not interact with suspicious links to fill every field. A submitted complaint is not a substitute for active technical response or a promise that someone will immediately take over.

Separate lost money from money arriving late

Downtime puts different kinds of pressure on a business. Emergency provider invoices, overtime, damaged stock, cancelled work, and delayed customer collections should not all become one undifferentiated loss estimate.

Delayed collections can create an immediate cash problem without every delayed dollar becoming permanently lost revenue. Lost sales can overlap with other estimates. Track categories and assumptions separately so the accountant, insurer, and owner can reconcile them without double counting.

For a rehearsal, the finance lead can identify the next payroll date, major upcoming payments, and the collections that depend on interrupted work. Use the company's own figures privately, not the fictional amounts in a video or a generic industry average.

The practical decision is which interruption creates pressure first and what lawful, safe continuity option exists. That answer informs recovery order. It does not justify exposing customer information or bypassing payment verification to make the numbers look better.

Run the second version before you need it

Repeat the Monday-morning exercise after resolving the first missing dependency. This time, ask people to show the contact, authorization, recovery evidence, or approved workaround they would rely on.

Keep a short record: assumption found, evidence checked, remaining limit, owner, and next review trigger. Revisit it after important provider, account, system, or staffing changes. The purpose is not to memorize a script. It is to remove predictable confusion while there is time to make ordinary decisions.

Start with the First Actions guide for the working records. Then book an incident-readiness conversation with Trawvid Sec to test the responsibilities and recovery paths behind your critical work. We prepare the business for those decisions; we do not promise uninterrupted operations or provide a 24/7 emergency response service through this article.