Security-aware managed IT: choose a provider with clear responsibilities

Define the assets and decisions in scope

List important accounts, devices, applications and information categories. Describe business impacts of lost access, disclosure or corrupted data without sending sensitive records. Identify who can approve changes, accept a documented risk and coordinate an incident internally.

Separate routine IT operations from specialist security work. Monitoring an endpoint, conducting an independent assessment and providing round-the-clock incident response are not interchangeable. Ask the provider to state which activities are contracted, which need another specialist and which remain your responsibility.

Examine the provider’s access to your systems

MSP access is itself a third-party risk. Ask about named technician accounts, multi-factor authentication, privilege limits, access logging and removal of access when staff leave. Find out whether remote-management tools can reach all clients or use more constrained arrangements.

CISA advises MSP customers to consider outsourcing risks and work jointly with providers to reduce them. Ask how the provider would notify you of a compromise affecting its own systems and how your access could be isolated. A broad assurance of trust is not a substitute for documented responsibilities and controls.

Ask what security operations actually do

Distinguish deploying tools from reviewing alerts and taking action. Clarify who monitors warnings, at what hours and with what authority to isolate a device or disable an account. Ask how false positives, missed signals and issues waiting for your approval are handled.

Request examples of reporting that identify findings, owners and next actions. Patching should include exceptions and follow-up rather than an unsupported claim that every device is current. No tool or provider can guarantee prevention of every attack; evaluate the operating process and its stated limits.

Agree on incident and recovery responsibilities

Identify contacts, notification expectations and escalation to insurers, counsel or specialist responders where relevant. Decide who preserves information, communicates internally and approves restoration. An MSP may assist, but it should not silently assume authority over legal notifications or public communications.

Ask how backups are protected and how restoration is tested for the systems in scope. Recovery objectives depend on technology, data and outside services. Request evidence of tests and unresolved limitations rather than interpreting the presence of backups as proof of immediate recovery.

Evaluate contracts without compliance shortcuts

Security-related obligations vary with your activities, information and jurisdiction. Have qualified advisors determine what applies. Ask the MSP to map its deliverables to your documented requirements, but do not treat a service package, certification claim or checklist as a guarantee of your compliance.

An engagement may begin with inventory, access review and a prioritized risk-remediation plan. Compare recurring support with assessments, monitoring, response retainers and remediation projects. Preserve account ownership, documentation access and a secure exit process. Select a provider that explains both its capabilities and the boundaries of its offer.

Questions for prospective MSPs

1. Who reviews alerts, during which hours, and what actions are authorized?
2. How would you notify us of an incident in your own environment?
3. Which response and recovery services require separate contracts?
4. How do you document limitations and transfer access at contract end?