MSP Incident Response: What Happens When Your Business Is Hacked?

Your IT provider may manage antivirus, backups, multifactor authentication, email security and monitoring. Those controls can reduce risk, but they cannot promise that an incident will never happen.

A useful question to ask before an incident is: what will our IT provider do when a security alert turns out to be real?

A compromised Microsoft 365 account, an infected laptop or an unexpected administrator sign-in can quickly become confusing if nobody knows who investigates, who can contain the issue, how management is updated or what evidence needs to be preserved. A clear MSP incident response process gives your business a practical way to make those decisions under pressure.

In this guide

Security controls do not replace incident response

Prevention remains important. Multifactor authentication, endpoint protection, patching, backups and secure configuration can all help lower the chance or impact of a cyber incident.

But a tool being installed does not prove that its alerts are monitored, understood and acted on. Your organisation also needs a response process: people with clear responsibilities, agreed authority, working contact routes and a way to document decisions.

The goal is not to assume that an incident is inevitable or that your MSP is unprepared. It is to understand the service you are relying on and identify gaps while there is time to address them.

What should happen after a Microsoft 365 account is compromised?

Suppose an employee reports an unusual sign-in or a customer receives a message that the employee did not send. The first step is to establish what is known, what may be affected and who is coordinating the response. The exact actions depend on the evidence, tenant configuration, available licences and your agreement with the provider.

A response may include:

• Contain the suspected access. The IT team may need to block sign-in, reset credentials, revoke sessions or take other steps appropriate to the account and incident. A password reset alone should not be assumed to end every active application session; Microsoft documents the available access-revocation behaviour and its limits in its Microsoft Entra emergency access guidance.
• Check how the account was used. Review sign-in activity, authentication changes, suspicious devices and other relevant audit records. Access to particular logs and their retention can depend on the tenant's licence and configuration.
• Look for changes made by the attacker. Examine mailbox forwarding, inbox rules, delegated access, suspicious applications and messages sent or deleted. Microsoft's compromised Microsoft 365 email account guidance describes investigation and remediation steps.
• Assess who or what else may be affected. Check for related phishing messages, other potentially compromised accounts, connected devices and business systems. The scope should be based on evidence rather than assumption.
• Coordinate communications and recovery. Your business should know who updates management, employees, customers, insurers and professional advisers when appropriate. Decisions about legal or regulatory notifications belong with the organisation and its qualified advisers.
• Record what was done. Keep a timeline of observations, containment actions, decisions, owners and recovery checks. Preserve relevant evidence where practical before taking actions that could remove it.

A provider does not need to promise a universal response sequence. It should be able to explain its process, the decisions that depend on your approval and what is included in the service you purchased.

Who monitors alerts—and when?

Many organisations have several systems that can generate security alerts: Microsoft Defender, identity protection, endpoint detection, email filtering, firewalls and backup platforms. Ask who receives alerts, how they are triaged and how critical items are escalated.

Also clarify the difference between alerts being generated and a person investigating them. Ask whether monitoring is continuous or limited to specified hours, what qualifies as an emergency, and what happens outside business hours. If the provider uses a third-party monitoring service, find out how the hand-off works and who remains accountable for contacting you.

An after-hours contact route should be tested. If the agreement has response targets, make sure you understand what the target measures—acknowledgement, investigation, containment or another milestone—and which incident types it covers.

Clarify roles before an incident

An MSP may manage systems and technical containment, while your business retains responsibility for business decisions, internal communications and engaging legal counsel or an insurer. Cybersecurity specialists, software vendors and law enforcement may also become involved depending on the circumstances.

Write down who can approve actions that could interrupt work, such as disabling accounts or isolating a device. Confirm who is authorised to contact your leadership team and where current emergency details are stored. The provider should explain which tasks are included, which require a separate incident-response engagement and how additional costs are handled.

A short responsibility map can help everyone understand:

• who receives and investigates alerts;
• who can approve disruptive containment actions;
• who leads the business response and keeps a decision log;
• who contacts employees, customers, the insurer and professional advisers;
• who validates recovery and confirms that normal operations can resume.

For complex incidents, your existing IT provider may need specialist support. Ask in advance whether it has an escalation partner, what access that partner may need and how your business authorises the work.

Ask your MSP to walk through one realistic scenario

A practical conversation can reveal more than asking whether a provider “does cybersecurity.” Choose a scenario relevant to your business, such as a compromised finance mailbox or ransomware detected on a managed laptop. Then ask the provider to explain the first actions and hand-offs.

Questions to ask include:

• Who receives the alert, and how is its severity assessed?
• What information do you need from us before taking action?
• How do you contain a compromised account or device?
• How will you investigate mailbox rules, forwarding, sign-ins and other affected accounts?
• What security logs are available, and how long are they retained?
• How and when will our management team be updated?
• What happens if the alert arrives outside support hours?
• Which response tasks are included in our agreement, and which are additional?
• What written incident summary and recovery evidence will we receive?

A capable provider should be able to describe the process in plain language, identify its limits and explain where your organisation needs to make a decision. “We have a security platform” is useful context, but it is not a complete answer to who acts when the platform raises an alert.

Test the plan before relying on it

A tabletop exercise is a discussion-based walk-through of a simulated incident. It does not require you to disrupt live systems. Your business and IT provider can use the scenario to check the contact list, decision authority, escalation route, communications and recovery responsibilities.

For example, consider an employee's mailbox being used to send fraudulent payment instructions. Ask what evidence is available, who coordinates containment, how affected contacts would be identified and who approves external communications. Record unclear responsibilities and assign an owner and target date to close each gap.

The exercise should be proportionate to the size of your business. Its purpose is to test whether the written plan works for the people expected to use it—not to stage a sophisticated technical simulation.

Microsoft's incident response overview provides additional context on organising a response and considering evidence during investigation.

Independent review can help verify readiness

Your MSP may have sound incident procedures. An independent review can help you understand how those procedures align with your agreement, your Microsoft 365 configuration and your business responsibilities.

Allegiance IT Advisory can review agreed evidence such as alert escalation, account-compromise procedures, administrator access, logging, after-hours arrangements, incident documentation and backup recovery responsibilities. We can help you identify questions for your provider and practical actions to consider.

This advisory review does not replace your MSP's operational response, a specialist digital forensics engagement or legal advice. If an active incident is in progress, follow your established emergency process and contact the appropriate technical and professional responders.

Know who does what before an incident happens

You do not need to predict every cyber incident. You do need to know who receives the first alert, who can take urgent technical action, how the business makes decisions and what evidence will be available afterward.

Ask your IT provider to walk through a realistic scenario, confirm what your agreement covers and document any unresolved questions. If you would like an independent view of your MSP's incident readiness or Microsoft 365 security arrangements, Allegiance IT Advisory can help you review the evidence and decide what to clarify next.

Keep your existing provider if it is working well. Add an independent perspective on whether the response process is clear, agreed and ready to use.