Security takeover checklist when inheriting an MSP client

Short answer: Treat a security finding during MSP transition as an incident first and a provider-performance question later. Protect the client, preserve evidence, establish the responsibility timeline, and document only what you can prove. Do not contact the previous MSP or name a product without a client-approved operational reason.

A takeover finding changes the onboarding priority

A new client rarely arrives as a clean environment. The first deployment may expose malware, an unknown administrator, a stale remote-access agent, an unsafe exclusion, or a device that was never covered by the previous security service.

That discovery creates two separate problems:

1. A security incident that may require immediate containment and investigation.
2. A transition question about what existed before the new MSP assumed responsibility.

Do not let the second problem delay the first. The client needs a coordinated response, not a debate about which vendor, tool, or provider should have seen the activity.

The finding also does not prove negligence. The previous service may have excluded the device, operated under a different scope, alerted without authority to remediate, retained evidence the client has not requested, or begun after the original compromise. Those possibilities are not excuses. They are unknowns that must be separated from facts.

Connect this guide to the broader client onboarding checklist. Normal onboarding can continue after the incident owner decides what must pause, what evidence must be preserved, and which systems are safe to touch.

Establish the handoff line before changing controls

Write down the transition line as early as possible:

• Date and time the new MSP received administrative authority.
• Date and time each new agent or control was installed.
• Date and time each previous agent or access path was removed.
• Devices that were online, offline, unavailable, or intentionally excluded.
• Security services the client says were included under the previous agreement.
• Alerts, open tickets, exceptions, and risk acceptances delivered at handoff.
• People authorized to approve isolation, evidence collection, restoration, and external communication.

This is not a blame document. It is an operating record. Without it, later conversations collapse into memory: the former MSP says the device was outside scope, the client says it was covered, and the new MSP cannot show when its own responsibility began.

If possible, avoid removing the former stack before recording agent presence, policy state, recent alert status, and device coverage. Do not access another provider's portal or data without authorization. Record only what is legitimately visible in the client environment or delivered through the handoff.

Contain without destroying the evidence you need

Follow the client's approved incident-response plan and the direction of qualified responders. For a confirmed or credible active threat, the first objective is to prevent additional harm while preserving enough evidence to understand scope.

Practical rules:

• Coordinate network isolation instead of improvising unrelated remediation steps.
• Preserve the original alert, timestamps, device identity, logged-in users, and actions already taken.
• Collect relevant endpoint, identity, firewall, DNS, proxy, authentication, and remote-access logs before retention expires.
• Record every containment and remediation action with time, operator, reason, and result.
• Do not reimage, wipe, delete accounts, or uninstall controls merely to make the alert disappear.
• Avoid powering down a device when doing so would destroy volatile evidence, unless isolation is not possible or the response lead directs it.
• Use an out-of-band channel if the threat may be monitoring normal communications.

The CISA ransomware response checklist emphasizes coordinated isolation and preservation of volatile evidence. The exact technical sequence depends on the threat and available responders, but the operating principle is stable: containment and evidence preservation must be planned together.

Open one incident record and build the timeline

Small teams lose incidents when evidence is scattered across chat, email, security portals, and technician notes. Create one incident record that owns the timeline.

Record:

• Who reported or detected the event.
• The first observed time and earliest known related activity.
• Device, account, tenant, site, and network context.
• Detection source and confidence level.
• Indicators and behaviors, not just a malware label.
• Which systems or accounts may share the same exposure.
• Actions requested, approved, executed, failed, or deferred.
• Evidence locations and retention deadlines.
• Client, insurance, legal, privacy, and regulatory contacts when applicable.
• The decision that closes containment and authorizes recovery.

Do not silently edit earlier observations when new evidence changes the story. Add a dated correction. A timeline should show how understanding evolved.

NIST SP 800-61 Rev. 3 places incident response inside ongoing cybersecurity risk management rather than treating it as an isolated technical event. For a small MSP, that means the incident record must connect technical response, client decisions, communications, recovery, and lessons learned. See NIST's current incident-response guidance.

Separate facts, inferences, and unanswered questions

Use three labels in the incident record.

Confirmed fact

Evidence directly supports the statement.

Examples:

• A specific device executed a suspicious process at a recorded time.
• An administrator account authenticated from a logged source.
• A security agent was installed on the device when the new MSP arrived.
• A containment action completed successfully.

Working inference

The evidence suggests the statement, but alternatives remain.

Examples:

• The activity may predate the transition.
• An unfamiliar local account may have been used for persistence.
• A policy or exclusion may have reduced automatic response.

Open question

The answer requires evidence not yet available.

Examples:

• Was the endpoint included in the previous managed-security scope?
• Did the previous provider receive an alert?
• Did the client decline a recommended control?
• Was remediation authority included in the prior agreement?

An installed agent is a fact. What the contract included is a question. A new detection is a fact. Why a previous workflow did not remediate is an inference until the alert and policy history are available.

The client owns the external communication decision

The new MSP's first communication duty is to the client and the designated incident owner. The former MSP is not automatically entitled to incident details, and the new MSP should not disclose the client's security information simply as professional courtesy.

Before contacting an outside party, confirm:

• The client authorizes the contact and the information to be shared.
• The contact has a defined incident-response purpose.
• Legal, insurance, privacy, or regulatory processes do not require a different channel.
• The message does not expose credentials, sensitive indicators, personal data, or unnecessary client details.
• One person owns follow-up and records the response.

The CISA risk considerations for MSP customers recommend clear protocols for vulnerability disclosure, incident notification, and communication with external stakeholders. Those protocols should be decided before an emotional message is sent.

When contacting the previous MSP may help

Contact can be operationally useful when:

• The previous provider retains logs needed to establish scope or timing.
• Its access or agent must remain temporarily for containment or evidence export.
• It owns a vendor case, backup, network control, or cloud relationship needed for recovery.
• The client needs confirmation of prior alert handling, exclusions, or risk acceptance.
• A confirmed shared credential or repeatable practice may create risk beyond one client.
• The client wants a coordinated transition record rather than competing narratives.

Contact is usually not useful when:

• The purpose is to warn that the new MSP has a better stack.
• The evidence only shows that one tool detected what another did not.
• The client has not authorized disclosure.
• The message speculates about negligence, competence, or product quality.
• The information will not change containment, investigation, recovery, or broader risk.

A systemic risk deserves stronger escalation than a one-off unexplained finding. Even then, use a documented, limited channel and share only the evidence needed to describe the risk.

Use a neutral communication template

With client authorization, a message can read:

During the authorized transition for our mutual client, we identified a security event that may include activity from before our service responsibility began. We do not have your contract scope, policy configuration, or complete alert history, so we are not attributing cause or responsibility. The client has authorized us to ask whether you retain alerts, logs, exceptions, or case information for the affected system and time range that could support containment and timeline review. Please use the agreed secure channel for any evidence or sensitive details.

Do not include unnecessary endpoint names, public indicators, usernames, screenshots, or full reports in the first message. Establish the authorized recipient and secure transfer method first.

Run a transition security sweep

The first finding may be isolated, or it may reveal a wider ownership problem. Review the environment systematically.

Identity and privileged access

• Inventory named administrators, shared accounts, emergency accounts, service identities, and delegated access.
• Disable access that is unauthorized or no longer required, after preserving relevant evidence.
• Rotate privileged credentials, API keys, remote-access secrets, and shared local administrator credentials using a documented sequence.
• Review recent privileged changes and authentication anomalies.

Endpoint coverage

• Reconcile the client asset list against active security and management coverage.
• Identify devices that are offline, duplicated, stale, unmanaged, or excluded.
• Verify policy assignment and alert routing rather than counting installed agents.
• Search for related indicators across the covered fleet.

Network and cloud control

• Review firewall, VPN, wireless, DNS, email, identity, backup, and cloud administration paths.
• Confirm which party owns each control and where logs are retained.
• Remove stale integrations and vendor access only after their role in the incident is understood.

Evidence and documentation

• Export handoff records, open risks, unresolved tickets, and known exceptions.
• Record unavailable evidence instead of pretending the review was complete.
• Give every residual risk an owner, decision, and review date.

The CISA logging guidance for small and medium businesses recommends assigning incident roles and preserving useful business-system records. Visibility only helps when somebody owns review and response.

Define a security floor for every managed client

The transition may expose a packaging problem. If a managed client can decline every visibility or response control while the MSP still carries an expectation to detect and fix incidents, the agreement creates responsibility without evidence.

Define the minimum security floor required to deliver managed service safely:

• Named administrative access and strong authentication.
• Endpoint inventory and minimum monitoring coverage.
• Central alert ownership and escalation.
• Patch, backup, and restore-path expectations.
• Log availability appropriate to the supported environment.
• A documented exception and risk-acceptance process.
• Authority boundaries for containment and emergency action.

Advanced response, formal compliance, forensic investigation, and regulated reporting may remain separate scope. The minimum floor is not a claim that every client receives every security service. It is the visibility and control the MSP needs to support its own promise.

Use the security baseline for small MSPs to define the recurring controls after the takeover incident is stabilized.

Complete an after-action review

After containment and recovery, review both the incident and the transition.

Ask:

• Which evidence was available immediately?
• Which logs expired or were inaccessible?
• Did the team know who could approve isolation?
• Did tool removal happen before evidence export?
• Were client, insurance, legal, and provider communications coordinated?
• Did any shared account, agent, or integration survive the handoff unexpectedly?
• Which checklist or contract boundary needs to change?

Assign each improvement an owner and due date. Do not close with “technician reminded.” Change the checklist, automation, agreement, access model, or review cadence that allowed the gap.

Takeover checklist

Before closing the transition review, confirm:

• The incident has one owner and one dated timeline.
• Affected systems were contained through the approved response process.
• Relevant evidence and logs were preserved before destructive action.
• Facts, inferences, and open questions are labeled separately.
• The responsibility and tool-transition dates are recorded.
• The client approved any contact with the former provider.
• Privileged and shared access has been reviewed and rotated.
• Endpoint, network, cloud, backup, and remote-access coverage is reconciled.
• Exceptions and unavailable evidence are documented.
• Residual risks have client decisions and review dates.
• Recovery and return-to-service decisions are recorded.
• The onboarding, offboarding, and incident checklists were updated from lessons learned.

Common mistake

The common mistake is turning the discovery into a sales story. “Our tool caught what theirs missed” sounds simple, but it ignores scope, configuration, timing, alert authority, and client decisions. It can also encourage premature remediation that destroys evidence needed by the client.

Let the operating record speak: what was found, when it was found, what was affected, what the team did, what remains unknown, and which decision protects the client next.

When to change level

Bring in specialized incident response, legal, insurance, privacy, or regulatory support when the event may involve lateral movement, privileged-account compromise, sensitive-data exposure, material business interruption, multiple clients, or notification duties beyond the MSP's competence or authority.

Strengthen the takeover process when credentials, agents, logs, ownership, or security exceptions repeatedly arrive undocumented. A transition should not depend on the new technician discovering the environment one surprise at a time.