What an MSP Does During a Cyberattack in the First 72 Hours

Before the Clock Starts

The quality of a response depends heavily on work completed before an attack. The MSP should know which systems are critical, who can authorize emergency changes, how to reach decision-makers outside company email, where logs are stored, which backups are isolated, and which outside partners must be called. It should also know the boundaries of its assignment. If forensic investigation, breach counsel, public relations, regulatory reporting, or ransom negotiation is outside the contract, the plan should name who performs that work.

This preparation reflects current NIST guidance. NIST Special Publication 800-61 Revision 3, finalized in 2025, treats incident response as part of broader cybersecurity risk management rather than a stand-alone emergency procedure. Detection, response, and recovery depend on decisions made across governance, asset identification, protection, and planning. The practical lesson for an SMB is direct: buying security tools is not the same as building a response capability.

Hours 0 to 1 Confirm the Event and Limit Immediate Damage

The MSP first determines whether the alert represents a real incident, a contained event, or a false positive. A help desk ticket saying that files will not open may point to ransomware, but it could also be a storage failure or permissions problem. A risky sign-in may be a traveling employee or a stolen session. The responder records what was observed, when it began, who reported it, and which systems or accounts appear affected.

Once malicious activity is reasonably suspected, containment takes priority. The MSP may isolate an endpoint through an endpoint detection platform, disable or restrict a compromised account, revoke active cloud sessions, block a known malicious address, or segment an affected server from the network. If several systems are involved, the MSP may recommend taking a subnet or service offline. These actions should be coordinated because a rushed shutdown can erase volatile evidence, interrupt critical operations, or prompt an attacker to change tactics.

CISA advises organizations to isolate impacted systems quickly and use out-of-band communications when attackers may be monitoring company email or chat. The MSP may move the response team to phone calls, a separate collaboration tenant, or another approved channel. Employees should receive a short instruction that tells them what to stop using and where to report new symptoms. Speculation about the cause or scope should wait until facts are verified.

What the MSP Records Immediately

• The first known alert, symptom, and reporting time
• Affected users, devices, servers, cloud services, sites, and business processes
• Containment actions, approvers, timestamps, and observed results
• Available logs, memory captures, system snapshots, messages, and suspicious files
• Known operational impact and the next scheduled leadership update

Hours 1 to 4 Establish Scope and Activate the Response Team

Containment buys time, but it does not answer the key questions. The MSP now works to establish scope: which identities were used, where the attacker entered, how far activity spread, what data or systems were reached, and whether the attacker still has access. Technicians correlate endpoint alerts, authentication records, firewall events, email traces, cloud audit logs, remote access records, and system changes. They preserve source files and record how evidence was collected so later analysis has a reliable history.

At the same time, the company activates the wider response team. Leadership sets business priorities. Legal counsel advises on privilege, contracts, and potential notification duties. The cyber insurer should be contacted through the policy’s approved process before the company hires unapproved specialists or incurs major costs. If the event is serious or technically complex, the MSP supports a digital forensics team with access, system context, inventories, and logs instead of trying to stretch beyond its competence.

The team also decides how it will classify the incident and how often leaders will receive updates. A useful update separates known facts, working hypotheses, business impact, actions completed, decisions needed, and the next reporting time. That format keeps uncertainty visible. It also helps leadership make choices without treating an early theory as a confirmed breach finding.

Hours 4 to 12 Contain the Threat Without Destroying Evidence

By this stage, the MSP should have enough information to move from emergency isolation to broader containment. Actions may include resetting exposed credentials from a known-clean device, revoking tokens, disabling suspicious forwarding rules, closing an exploited remote access path, removing unauthorized administrative accounts, updating firewall controls, or deploying detection rules across managed endpoints. If the root cause remains uncertain, the team may keep selected systems isolated for forensic review rather than cleaning them immediately.

Backups receive special attention. The MSP verifies that backup consoles and storage accounts have not been accessed with compromised credentials, protects immutable or offline copies, and pauses automated processes that could overwrite clean recovery points. A green backup status alone is not enough. The team needs to know when the data was captured, whether the source was already compromised, and whether a representative restore works in an isolated environment.

Business continuity runs alongside technical containment. The company may need temporary laptops, alternate email, manual dispatch, limited access to accounting, or a clean method for sharing project files. For a contractor in Raleigh, an engineering firm in Durham, or a multi-office business in New York City, the order of restoration should follow business impact. Payroll, safety, client deadlines, regulated data, and revenue-critical work may deserve different priorities. The MSP translates those priorities into a technical recovery sequence.

Hours 12 to 24 Prepare a Trusted Recovery Path

Recovery should begin only when the response lead agrees that the environment is ready. Restoring too early can bring an attacker back into service or contaminate clean systems. The MSP and any forensic specialists look for the initial access route, persistence mechanisms, privileged account misuse, lateral movement, malware, and signs of data collection or exfiltration. They document what is confirmed and what remains unknown.

The MSP then builds a recovery plan by service. Each workload needs an approved source, a clean target, a credential plan, a validation owner, and a rollback option. Systems may be rebuilt from known-good images rather than simply decrypted or cleaned. Credentials should be changed in an order that avoids exposing new passwords through compromised identity infrastructure. Internet-facing services should receive fixes or compensating controls before they are returned to production.

Communication also becomes more formal. The FTC recommends a coordinated response that includes technical, legal, operational, and communications expertise, along with careful documentation and fact-based notices. The MSP supplies technical facts, but legal counsel should determine whether an event meets a contractual, state, federal, or industry notification threshold. Customer and employee messages should state what is known, what people should do, and when the next update will arrive. They should not guess at the attacker, data affected, or final cause.

Hours 24 to 48 Restore Priority Services and Watch Closely

Restoration usually proceeds in controlled waves. Identity services, network controls, security monitoring, core applications, file systems, and user devices must return in an order that preserves trust. Before releasing a service, the MSP applies required patches and configuration changes, verifies endpoint protection and logging, confirms access rights, tests the application with its business owner, and records the result. Reconnecting everything at once makes it harder to identify the source if malicious activity resumes.

The MSP increases monitoring across the recovered environment. Analysts watch for the same indicators that appeared during the incident as well as new logins, unexpected administrative changes, disabled security tools, unusual data movement, and renewed command-and-control traffic. Recovery metrics should focus on business function, not only device counts. Saying that 80 percent of computers are online is less useful than confirming that payroll can run, employees can reach approved files, and customer communications are functioning.

If ransomware is involved, the company should coordinate payment questions with legal counsel, the insurer, law enforcement, and qualified specialists. The FBI does not support paying a ransom because payment encourages criminal activity and does not guarantee data recovery. The MSP’s role is to provide technical evidence about backup viability, restoration options, system impact, and the practical risks of each path. It should not make the business or legal decision alone.

Hours 48 to 72 Stabilize Operations and Start Corrective Work

By the third day, some incidents will be moving toward stable operations, while others will still be under active investigation. The MSP continues restoring lower-priority services, validating user access, replacing compromised devices, and monitoring for recurrence. Temporary controls should be tracked so they do not become permanent blind spots. Exceptions, emergency accounts, blocked integrations, and manual workarounds all need owners and review dates.

The response lead should also preserve a decision log and a current incident narrative. That record supports legal review, insurance claims, customer communication, and the later lessons-learned meeting. It should show what happened, how the team detected it, which assets and business functions were affected, what containment and recovery steps were taken, and which uncertainties remain. The document should avoid conclusions that the evidence does not support.

Corrective work starts before the incident is formally closed. The MSP may recommend closing the entry point, strengthening multifactor authentication, reducing administrative access, improving email controls, extending log retention, changing remote access, segmenting networks, or redesigning backups. The final priority list should connect each action to a finding from the incident. A generic security shopping list is not a substitute for fixing the conditions that made the attack possible or difficult to contain.

What the MSP Should Own and Where Its Role Ends

A prospective client should ask an MSP to describe its incident responsibilities in writing. The agreement should explain monitoring and alerting coverage, escalation times, after-hours contacts, containment authority, log access, backup recovery duties, documentation, vendor coordination, and any separate fees. It should also state whether the provider offers security operations, digital forensics, breach notification support, or only managed IT. The label MSP does not guarantee the same response capability from every provider.

During an incident, a capable MSP commonly owns or supports technical triage, isolation, account controls, log collection, system inventories, backup validation, rebuilding, restoration, and operational monitoring. It may coordinate with Microsoft 365, cybersecurity vendors, internet providers, software vendors, and the internal IT team. That coordination is valuable because the MSP already knows the environment and can turn business priorities into technical work.

The MSP should not independently decide whether a breach is legally reportable, whether to notify customers, whether to pay a ransom, or what the company should say publicly. It should not promise that no data left the environment when available logs cannot prove that. It should not erase systems merely to restore service faster. Clear boundaries protect the investigation and help each adviser do the job for which it was engaged.

How to Prepare Your MSP Before an Incident

The best time to evaluate MSP cyber incident response is before an emergency. A planning session should end with named people, working contact methods, tested access, and a recovery order that leadership understands. Use these questions to structure the conversation.

1. Who declares an incident, and what can the MSP isolate without waiting for approval?
2. How do we reach the MSP, leadership, legal counsel, and the cyber insurer if company email is unavailable?
3. Which systems, identities, vendors, and data are most important to operations?
4. Which security and cloud logs are retained, for how long, and who can export them?
5. Are backups isolated from normal administrative accounts, and when was the last successful restore test?
6. Which outside forensic, legal, communications, and recovery firms are approved by the insurer?
7. What are the recovery time and recovery point objectives for each critical service?
8. How will employees, customers, and vendors receive accurate updates?
9. When will the team run a tabletop exercise and update the plan?

A tabletop exercise can expose gaps without taking production systems offline. Give the team a realistic scenario, such as a compromised administrator account followed by encrypted file shares. Ask participants to make the first-hour decisions, locate contact information, identify the evidence they need, and choose which service returns first. Record every assumption that fails. Those failures become the next planning tasks.

Frequently Asked Questions

Can an MSP stop every cyberattack

No. An MSP can reduce risk, detect suspicious activity, contain incidents, and support recovery, but no provider can guarantee that every attack will be prevented. The contract, tools, access, staffing, and preparation determine what the MSP can do.

Should employees turn off an infected computer

Usually the safer first step is to disconnect the device from wired and wireless networks and call the incident contact. Powering it off can destroy evidence stored in memory. If isolation is impossible and the threat is spreading, the response team may direct the user to shut it down.

Does an MSP handle breach notification

The MSP supplies technical findings and affected-system information. Legal counsel should determine notification duties and timing based on the data, jurisdictions, contracts, and regulations involved. The MSP may help prepare accurate technical language after counsel and leadership approve the message.

When should a cyber insurance carrier be contacted

Contact the carrier or broker as soon as the policy and incident plan require. Many policies specify notice procedures and approved legal, forensic, negotiation, or recovery vendors. Delayed notice or unapproved spending can complicate coverage.

Can an MSP recover the business within 72 hours

Sometimes, but the timeline depends on scope, system complexity, backup quality, attacker persistence, regulatory needs, and available replacement infrastructure. The first 72 hours should produce control, reliable facts, a prioritized recovery path, and visible progress. Full restoration may take longer.

What should we ask an MSP before signing a contract

Ask for the incident escalation process, after-hours coverage, containment authority, log retention, backup testing, recovery responsibilities, documentation standards, specialist partnerships, insurance requirements, and fees. Then test the process in a tabletop exercise.

Build the Response Plan Before You Need It

A cyberattack compresses technical, legal, and business decisions into a few hours. A prepared MSP gives the company a reliable technical lead, a current picture of the environment, and a disciplined route from containment to recovery. The real advantage begins before the alert: written authority, usable logs, protected backups, known partners, and an exercised plan.

Computerbilities helps businesses in Raleigh, Cary, Durham, the NC Triangle, and New York City plan the IT and recovery work that supports an incident response. Start with an incident-response planning conversation to review critical systems, escalation contacts, backup readiness, provider responsibilities, and the first decisions your team would need to make.

Recommended CTA  Schedule a free 15-minute IT risk call