Cyberattack Recovery for Small Businesses: A 24-Hour, 7-Day & 30-Day Playbook

When a small or midsize business discovers a cyberattack, the first priority is not restoration -- it is a coordinated, evidence-preserving response. The right sequence is to activate your incident-response process, contain the threat without triggering further damage or destroying evidence, contact the relevant IT or security provider, notify your cyber insurer when your policy applies, and begin assessing potential data exposure. The exact priorities depend on the nature of the incident, the systems affected, your business-continuity risks, and the legal or contractual obligations that may apply.

What Should You Do in the First 24 Hours After a Cyberattack?

The first 24 hours are about containment, evidence, and getting the right people involved -- not about fixing everything at once. How quickly and effectively you move in this window shapes everything that follows, including your ability to investigate the incident, meet any legal obligations, and make an insurance claim.

The ten priorities below are not a rigid linear sequence. Some can run in parallel; others depend on what you find. What matters is that none of them are skipped entirely.

For incidents involving ransomware specifically, the dynamics are different enough to warrant a dedicated read. The ransomware attack recovery guide covers what actually happens during a ransomware incident -- from initial compromise to negotiation and restoration decisions.

What Should Happen During Days 2–7?

Once the immediate containment and notification steps are underway, the focus shifts to investigation: understanding the scope of the compromise, identifying how the attacker got in, and building a safe plan for controlled recovery. This phase is about discovering what you don't yet know -- not moving quickly to restore.

Investigation priorities

• Determine the likely initial access route -- phishing, unpatched vulnerability, compromised credential, supply chain -- so the entry point can be closed.
• Identify compromised accounts, endpoints, servers, cloud services, and applications. A single confirmed compromise rarely marks the full scope.
• Establish whether sensitive data may have been accessed, altered, deleted, or exfiltrated, and what categories of data are involved.
• Look for persistence: evidence that the attacker has installed backdoors, created new accounts, modified scheduled tasks, or otherwise maintained access. CISA guidance specifically flags new or escalated Active Directory accounts, unexpected RMM software, and anomalous VPN logins as indicators to investigate.
• Review available backups and assess their integrity before any restoration. Confirm that backups predate the compromise and have not been modified or encrypted.
• Reset or rotate compromised credentials and secrets in a coordinated way -- not piecemeal in a way that alerts the attacker or misses affected accounts.
• Validate identity controls, administrative access, and remote access mechanisms before relying on them.
• Develop a prioritized restoration plan based on business criticality.
• Document all decisions, findings, and outstanding risks in writing.

If your business does not have an MSP or internal IT team, this is the phase where qualified external assistance is most critical. Decisions about restoration sequencing and credential rotation made without adequate investigation can undo containment and reset the incident clock.

What Should Happen During Days 7–30?

The 7-to-30-day phase is where incident response transitions into controlled recovery and early remediation. The incident may not be fully resolved within 30 days -- complex attacks, regulatory investigations, or insurance processes can extend well beyond that -- but this window is where the most consequential improvement decisions get made.

Recovery and remediation actions

• Complete root-cause analysis to the extent the available evidence supports. This means confirming the initial access vector, understanding the attacker's movement through systems, and identifying the specific controls that failed or were absent.
• Address the vulnerabilities, compromised identities, or process failures directly involved in the incident before broader improvements.
• Restore remaining systems in a controlled, monitored sequence. Prioritize by business impact. Monitor restored environments for signs of re-compromise.
• Verify that backups and recovery procedures actually work. A backup you haven't tested is a backup you cannot rely on under pressure.
• Review privileged access, MFA enforcement, remote access, and identity controls across the organization -- not just the affected systems.
• Improve endpoint protection, monitoring, alerting, and log retention where the incident exposed gaps.
• Reassess third-party access and vendor dependencies. Many compromises travel through supply chain or MSP access pathways.
• Update the incident-response and business-continuity plans based on what this incident revealed.
• Conduct a formal lessons-learned review involving IT, leadership, and any external responders.
• Assign owners and deadlines for each remediation action.

Not everything needs to happen at once. Distinguish between actions that directly address the incident's root cause -- which are urgent -- and broader security improvements that are genuinely valuable but can be prioritized sensibly over time. A small business without a dedicated security team does not need every available security control. It needs the controls most relevant to its actual risk profile and the specific failure modes this incident revealed.

When Should You Call an Incident-Response Firm, MSP, MSSP, or Other Specialist?

Provider categories in cybersecurity are not standardized, and the label does not tell you what a specific firm will actually do during your incident. Before relying on any external provider, confirm their actual capabilities, response times, scope of authority, and contractual exclusions.

Understanding the provider types

Incident-response firm. Typically focuses on investigating and containing an active or suspected incident, determining scope, supporting recovery, and preserving evidence within the agreed engagement. When an incident is active and exceeds internal capabilities, this is usually the first specialist call.

Managed Service Provider (MSP). Typically manages IT operations -- devices, systems, cloud environments, support, and infrastructure. Security capabilities vary significantly by provider. Many MSPs have incident-response procedures, but "MSP" alone does not guarantee that capability. Know what yours covers before an incident occurs.

Managed Security Service Provider (MSSP). Typically provides ongoing security services such as monitoring, alerting, detection, and other agreed security operations. The scope of authority to act -- whether the MSSP can contain or isolate systems unilaterally, for example -- varies by contract.

Managed Detection and Response (MDR) provider. Provides a detection-and-response-oriented service, often including active response capabilities. As with MSSPs, the actual operating model, scope, and authority depend on the contract, not the label.

Digital forensics specialist. Preserves and analyzes evidence, reconstructs the attack timeline, and supports investigations where scope or legal proceedings are in question. Relevant when the incident is complex, disputed, or may result in litigation or regulatory action.

Legal counsel. Assesses legal obligations, contractual requirements, privilege considerations, and notification duties. Involving legal counsel early can also help protect the confidentiality of the investigation. This is particularly important when a breach may trigger state, federal, or sector-specific notification requirements.

Crisis communications specialist. Relevant when the incident has significant customer, employee, reputational, or media implications. External communications coordinated without legal and technical input frequently make things worse.

Not every incident requires all of these providers. A contained phishing compromise with no data exposure and a capable MSP may require only internal response plus legal review. A ransomware event with potential customer data theft and regulatory implications is a different situation entirely.

If you are evaluating cybersecurity firms before or after an incident, the cybersecurity companies report lists firms across security service categories -- though any provider's specific incident-response capabilities and availability should be verified directly before engagement.

How Should You Work With Your Cyber Insurer During Recovery?

Cyber insurance policies vary significantly. Coverage terms, notification requirements, approved-provider requirements, and exclusions differ by carrier and policy. Do not assume what is or isn't covered -- read the policy and contact the insurer directly.

The most consistent advice from cyber insurance practitioners is: notify promptly, before incurring significant response costs, and before making any public statements or ransom-related decisions.

Key insurance response steps

• Review the policy's incident-reporting process immediately. Some policies set fixed notice periods. Others require notice "as soon as practicable." Late notice has caused coverage disputes and denial of pre-notice legal or forensic costs.
• Contact the insurer directly. Broker notice alone may not satisfy the policy's requirements. Send direct notice as well.
• Ask about approved incident-response, legal, forensic, and recovery providers. Many policies require or strongly prefer pre-approved vendors. Using an unapproved firm can complicate reimbursement.
• Preserve all relevant expenses, communications, and evidence. Business interruption claims depend on documented losses. Keep records of recovery costs, downtime, and staff time from the start.
• Do not assume coverage. Ransom payments, regulatory fines, certain business losses, and third-party claims may or may not be covered under your specific policy. Confirm before acting on assumptions.
• Coordinate technical, legal, and insurer communications. Statements made during the response -- including to the insurer -- can affect coverage determinations. Legal counsel familiar with cyber insurance can help.

For a thorough guide to cyber insurance coverage requirements, how MSPs affect policy terms, and what the current market looks like, see the 2026 cyber insurance requirements guide.

How Do You Restore Operations Without Reintroducing the Threat?

Restoring operations before confirming that the threat has been fully eradicated is one of the most common ways businesses extend their incident. A system that looks clean and a system that is clean are not the same thing.

Principles of safe recovery

Confirm containment before restoration. CISA's guidance is explicit: do not rebuild from backups until you have identified and removed persistence mechanisms, or the compromise may continue. "Avoid reinfection. For example, add only verified clean systems to any recovery VLAN."

Assess backups before using them. Check that the backup predates the compromise. Verify that it has not been encrypted, modified, or corrupted. Some ransomware specifically targets and destroys shadow copies and backup configurations before deploying. A backup that exists is not automatically a backup that is usable or safe.

Prioritize by business impact. Not everything needs to come back at once. Identify which systems are most critical to operations and restore in that order, monitoring each stage before proceeding.

Rebuild or clean using a documented process. Where possible, rebuild affected systems from standard, known-good images rather than attempting to clean infected machines. Use infrastructure-as-code approaches for cloud resources where applicable.

Restore identity and access controls first. Directory services, authentication systems, and privileged access controls should be validated and restored with confidence before dependent applications.

Validate workflows and data integrity. After restoration, confirm that critical business processes work correctly and that data has not been altered in ways that affect business operations.

Monitor restored environments. Treat recently restored systems as elevated-risk for a period after recovery. Increased logging and alerting during this window can catch re-compromise before it spreads.

If software vulnerabilities contributed to the incident, software testing and validation practices become particularly relevant before restoring any affected applications to production. And if the recovery involves patching or rebuilding systems with code changes, DevSecOps practices that embed security into the development and release process help prevent the same class of vulnerability from re-entering the environment.

What Should You Fix to Reduce the Chance of Another Attack?

Recovery without remediation is just an incident waiting to repeat. But not every SMB needs every security control -- the most valuable improvements are the ones directly relevant to how this incident happened and what your actual risk profile looks like.

High-priority controls to review after an incident

Multi-factor authentication. Account compromise, credential theft, and phishing are consistent initial access vectors. MFA on email, remote access, and administrative accounts is among the highest-impact single controls for most SMBs. Review enforcement -- not just enrollment -- across all critical accounts.

Least-privilege access. Accounts and systems should have only the access they genuinely need. Over-privileged accounts amplify the impact of any compromise. After an incident, review administrative accounts, service accounts, and vendor access.

Endpoint detection and response (EDR). Basic antivirus does not provide the telemetry needed to investigate modern attacks. Where appropriate to the business's size and risk, EDR tools provide visibility into what is happening on endpoints during and after an incident.

Backups -- tested, appropriately isolated, and ideally immutable. The value of a backup is determined by when it was last tested, not when it was last run. Backups should be isolated from the production environment (to prevent encryption during a ransomware event) and tested regularly through actual restoration exercises.

Patch and vulnerability management. Unpatched systems and software remain a primary attack surface for SMBs. Establish a consistent patching cadence, and prioritize internet-facing systems and those running software with known vulnerabilities.

Logging, monitoring, and alerting. You can only investigate what you have logs for. After an incident, assess what telemetry was missing that would have helped detect or contain it earlier. This informs log retention and monitoring investments.

Email security and phishing protections. Email remains a primary initial access vector. Review DMARC, DKIM, and SPF configurations; anti-phishing controls; and user reporting mechanisms.

Employee training tailored to actual risks. Generic awareness training has limited value. Training that reflects the attack types your business actually faces -- specific phishing tactics, social engineering methods -- is more likely to change behavior.

Vendor and remote-access controls. Remote access pathways -- VPN, RDP, third-party tools -- and vendor access are consistently exploited. Review who has remote access, under what conditions, and with what authentication requirements.

Documented incident-response procedures. Having a written plan before the next incident reduces the decision time and communication failures that amplify harm during response.

For businesses looking to take a more structured approach to access control and lateral movement prevention, the zero trust security guide covers what zero trust actually means in practice and when it makes sense for a business of your size.

A Practical Recovery Checklist for Business Owners

The windows below are planning guides, not guaranteed completion timelines. Complex incidents -- particularly ransomware, suspected data theft, or regulatory involvement -- often take longer to fully resolve. Use this checklist as a starting structure, not a deadline.