10 CISA Aligned Tests to Vet MSPs in Information Security for CISOs

An MSP in information security is a third-party provider that takes on continuous monitoring, threat detection, and a defined share of incident response for your organization. You should bring one on when you lack 24/7 coverage, face a skills gap on your team, or need to meet a compliance deadline faster than you can hire. The payoff worth demanding in return is clear: ongoing detection plus a written map of who responds when something breaks.

TL;DR:

• Choosing an MSP is most beneficial when internal skills are lacking or quick compliance deadlines require external support, especially for 24/7 threat detection.
• An MSP’s core technical capabilities should include MDR, IAM, vulnerability management, and log retention of at least six months, with clear SLAs for detection and response times.
• Vetting must go beyond marketing claims by reviewing architecture diagrams, audit reports, staff certifications, incident escalation procedures, and verifying MFA and log retention proof.
• Supply chain risks are significant; confirm the MSP discloses subcontractor use, software dependencies, and has a documented supplier risk assessment process.
• Clear, written responsibility sharing and regular testing through tabletop exercises help prevent blame disputes during incidents.

How an MSP differs from an MSSP and an in-house team

The terms get used interchangeably, and that looseness causes real contract problems later. An MSP, or managed service provider, typically handles broad IT operations: networks, help desk, backups, and increasingly, a security layer bundled on top. An MSSP, a managed security service provider, specializes narrowly in security operations, threat detection, and incident response, often running a dedicated security operations center (SOC). An in-house team keeps every function internal, with direct control over tooling, policy, and personnel but also full responsibility for staffing a 24/7 rotation.

Three engagement models cover most real-world arrangements:

• Fully managed: the provider owns monitoring, alerting, and a large share of remediation, with your team setting policy and approving major changes.
• Co-managed: the provider supplies tooling and after-hours coverage while your internal staff retains day-to-day ownership and escalation authority.
• Staff augmentation: the provider places analysts or engineers inside your existing processes, filling skill or headcount gaps without taking over the program.

Responsibilities split differently in each model. Policy ownership, meaning the rules that define acceptable risk, almost always stays with the client, regardless of model. Monitoring and alerting are the most commonly outsourced functions, since they require constant staffing that’s expensive to replicate internally. Remediation, the actual fix for a vulnerability or compromised account, is where contracts get vague most often, and it’s the single clause worth the most scrutiny before signing anything.

Expect different outcomes from each setup. A fully managed arrangement should produce a steady stream of triaged alerts and a documented incident history. A co-managed model should produce joint runbooks and a shared dashboard your team can audit anytime. Staff augmentation should produce measurable throughput against a backlog, not a transfer of ownership.

Core services an information security MSP should provide

Before signing anything, confirm the provider actually delivers the technical stack this role requires, not just a help desk with a security label attached. The baseline capability set includes:

• Detection and response: managed detection and response (MDR), endpoint detection and response (EDR), or extended detection and response (XDR), tied to a security information and event management (SIEM) platform with staffed SOC analysts doing threat hunting and triage.
• Identity controls: identity and access management (IAM), privileged access management (PAM), credential vaulting, and multi-factor authentication (MFA) enforced on every privileged account, including the MSP’s own.
• Data and perimeter protection: patch and vulnerability management on a fixed cadence, data loss prevention (DLP), email and cloud security, and increasingly secure access service edge (SASE) or zero-trust network architecture.
• Service-level guarantees: 24/7 monitoring with published detection and response time targets, a defined reporting cadence, and an appropriate log retention period.

That last point deserves a specific number. Joint guidance from international cybersecurity authorities, including CISA’s advisory on protecting against threats to MSPs, recommends storing the most critical security logs for at least six months to support detection and post-incident analysis. a substantial period of retained logs, gives investigators enough history to trace how an intrusion started, not just how it ended.

Ask every candidate MSP to state these capabilities in writing, with specifics rather than marketing language. “We monitor your environment” is not a service level. “We detect and acknowledge critical alerts within 15 minutes, 24/7, with a documented escalation path” is. If a provider can’t produce that sentence for your contract, keep looking.

Business cases and trade-offs: when an MSP is the right choice

An MSP earns its cost fastest in three situations: when you can’t recruit enough security analysts to cover nights and weekends, when you need predictable monthly costs instead of the salary and tooling spend of a full SOC build, and when a compliance deadline is closer than your hiring timeline allows.

The trade-offs are real and worth naming before you sign anything.

• Third-party access risk: an MSP with administrative rights to your environment becomes a new attack surface, and a compromise on their side can become a compromise on yours.
• Supply-chain dependence: your security posture now depends partly on a vendor’s own patching, staffing, and subcontractor practices, which you can’t fully control.
• Scope boundaries: “managed security” rarely means every security function, so gaps appear wherever the contract is silent.

The model you pick should track the actual gap you’re trying to close. If you need deep SOC expertise but want to keep policy and remediation decisions internal, an MSSP focused purely on detection and response fits better than a generalist MSP. If you have some internal security talent but not enough for round-the-clock coverage, a co-managed model lets you keep ownership of the parts you’re good at while buying coverage for the parts you’re not. Building fully in-house still makes sense for organizations with the budget and recruiting pipeline to staff a 24/7 team, and for those whose risk tolerance makes third-party access unacceptable.

Vetting checklist and contract clauses: what to require before you sign

Treat MSP selection like a security audit of a vendor, not a procurement exercise. The documentation an MSP can produce on request tells you more than any sales deck.

1. Request architecture diagrams and SOC runbooks so you can see how alerts flow from detection to human review, and who touches your data along the way.
2. Ask for recent audit or penetration test reports covering the MSP’s own environment, not just case studies about past clients.
3. Review staff training records to confirm analysts hold current certifications and get regular incident-response drills.
4. Put explicit ownership language in the contract stating who patches systems, who tests hardening, and who leads incident response when something goes wrong.
5. Set incident notification timelines in writing, specifying how many hours the MSP has to notify you after detecting a compromise.
6. Require MFA on every account the MSP uses to access your systems, with no exceptions for legacy tools or shared logins.
7. Define log retention and access audit requirements in the contract itself, not as a verbal assurance.
8. Confirm SOC staffing hours, detection and response SLA numbers, and the cadence of tabletop exercises or simulated incidents.
9. Ask for subcontractor disclosure, since many MSPs route part of their work through third parties you’ve never vetted.
10. Verify claims with a live demo or reference check rather than accepting a case study at face value.

CISA’s vendor SCRM template for small and medium-sized businesses builds a vetting use case specifically for MSPs with critical administrative access, listing the documentation and questions to request during evaluation. A related CISA fact sheet on assessing vendors and suppliers adds checklist items like documented hardening standards and incident detection and recovery processes, which belong in any RFP scoring sheet.

Pro Tip: Simulate a fake incident during the evaluation call and ask the MSP to walk through their actual notification and escalation steps; how fast and how specific the answer is tells you more than any proposal document.

Supply chain risk: what to verify about an MSP’s third-party exposure

MSPs are attractive targets precisely because compromising one provider can open a path into every client it serves. Joint guidance from international cybersecurity authorities, including NCSC, ACSC, CCCS, NCSC-NZ, CISA, NSA, and FBI, warns that MSPs are increasingly targeted for exactly this reason, and recommends customers treat MSP access as a distinct risk category rather than an extension of trusted internal IT.

Before signing, audit these specific areas:

• Subcontractor use: ask whether the MSP routes any part of monitoring, patching, or support through third parties, and request the same vetting documentation for those subcontractors.
• Software dependencies: request a software bill of materials (SBOM) or equivalent inventory for the tools the MSP deploys inside your environment.
• Vendor risk assessments: ask how the MSP evaluates its own suppliers, and whether it maintains a documented supplier qualification process.
• Procurement controls: confirm the MSP has a change management process that flags when a new tool or subcontractor enters the supply chain.

CISA’s SCRM resource guide for SMBs recommends maintaining a supplier list prioritized by criticality, which applies directly to an MSP relationship: ask for the MSP’s own version of that list, including past incident history disclosure, to calculate where a single point of failure might sit in the chain.

Operational controls you can verify quickly

Several controls are checkable within a single call or document request, and they correlate strongly with how seriously an MSP takes its own security.

• MFA on every privileged and MSP account, including service accounts, with no shared logins across customers.
• Log collection and retention feeding a SIEM or dedicated logging tool, reviewed regularly by SOC staff rather than just stored.
• Network segmentation separating the MSP’s access path from your broader internal network, with a dedicated, auditable connection method.
• Hardening standards and automated patch cadence, backed by documented configuration baselines you can request a copy of.

Joint advisory guidance from CISA and international partners specifically flags log retention of at least six months as a baseline for detection and incident analysis, along with MFA enforcement and network segregation as controls that customers should confirm rather than assume. None of these require trusting a vendor’s word: each one has a document, a configuration screen, or a report that proves it exists. A provider that can’t produce evidence for any of these four items within a business day is telling you something about how mature its own program actually is. For your own side of the relationship, a small business cybersecurity checklist covers the parallel controls your internal team should keep regardless of what the MSP handles.

Documenting shared responsibilities and testing recovery

Clarity on who does what prevents the most common post-incident argument: both sides assumed the other was handling it.

1. Write shared-responsibility language directly into the contract and joint runbooks, naming who performs hardening, who runs day-to-day detection, and who leads incident response during a live event.
2. Verify incident response capability with tabletop exercises and runbook reviews, and ask for evidence of past drills rather than a description of the process.
3. Check access governance, including role-based access control (RBAC), time-limited privileged access, full audit trails, and a documented deprovisioning procedure for when the contract ends.

A guide on responding to a data breach outlines the kind of recovery sequence your MSP’s runbook should mirror, step for step.

Compliance and regulatory considerations when using MSPs

Outsourcing security work doesn’t transfer regulatory liability. Most data protection and sector-specific regulations hold the data owner responsible for how that data is protected, even when a third party does the day-to-day work. That means your contract needs to specify which compliance obligations the MSP directly supports, such as evidence collection for audits, and which ones remain entirely yours, such as breach notification to regulators.

Ask any MSP candidate which frameworks they have direct experience supporting for clients in your sector, and request sample audit evidence they’ve produced before, not just a list of certifications they hold internally. If your organization operates under multiple regulatory regimes across different regions, confirm the MSP can tailor reporting and retention practices to each one rather than applying a single generic template.

Documentation matters as much as the controls themselves during a regulatory review. An MSP that can hand you a clean audit trail, mapped to your specific compliance requirements, on short notice is worth more than one that promises compliance support in general terms. Build a clause into the contract requiring the MSP to produce compliance-relevant evidence within a set number of business days of a request, and test that clause once during onboarding rather than waiting for an actual audit to find out it doesn’t work.

Cost considerations and pricing models for MSP services

MSP pricing in information security generally follows one of three structures: per-user or per-device monthly fees, tiered packages bundling a fixed set of services, or custom enterprise contracts scoped to a specific environment. Per-user pricing scales predictably as headcount changes, which makes budgeting easier for growing organizations, while tiered packages suit buyers who want a fixed monthly number regardless of usage.

The cheapest option on paper is rarely the cheapest option in practice. A low monthly fee that excludes incident response, log retention beyond a few weeks, or after-hours escalation can cost far more during an actual incident than a higher-priced package that includes those items upfront. Before comparing quotes, build a like-for-like list of what each provider includes at its base price versus what triggers an additional charge, since incident response, forensic support, and extended retention are the line items most often billed separately.

Ask for pricing broken out by service component rather than a single bundled number, so you can see exactly what you’re paying for detection versus response versus reporting. That breakdown also makes it easier to negotiate scope up or down as your internal team’s capabilities change, without renegotiating the entire contract from scratch.

Trends and future developments in MSP information security offerings

Several shifts are reshaping what buyers should expect from an information-security MSP over the next few years. Extended detection and response (XDR) platforms are increasingly replacing siloed EDR and SIEM tools, giving MSPs a single pane of glass across endpoints, network, and cloud, which should translate into faster triage for clients.

Zero-trust architecture is moving from a buzzword into a procurement requirement, particularly for MSPs serving regulated industries or government clients, and more providers are building SASE offerings to support it. Expect more MSPs to formalize supply-chain risk management on their own side, partly in response to the advisory guidance cybersecurity authorities have issued about MSPs as attack vectors, meaning tighter subcontractor disclosure and SBOM practices becoming standard rather than optional.

Passwordless authentication and stronger identity governance are also becoming baseline expectations rather than premium add-ons, as credential theft remains one of the most common entry points into MSP-managed environments. Buyers evaluating providers in 2026 should ask explicitly how each of these areas fits into the roadmap, not just the current service catalog, since a provider still building toward zero trust or passwordless access may need a longer runway than your compliance deadline allows.

Common MSP onboarding mistakes and what good looks like

The most frequent mistake is a contract that says “monitoring” without saying “remediation,” leaving clients assuming both are covered when only one is. A close second is skipping deprovisioning planning until the relationship ends, by which point access cleanup becomes an emergency.

Good onboarding looks like phased access, an initial hardening sprint in the first weeks, and joint runbooks built before the first real alert fires. Expect rough edges through month one and real operational maturity by month six, not sooner.

— Mike

An adjacent control: managing MSP credential risk with LogMeOnce

Every control in this guide assumes the MSP relationship itself is secure, and credentials are usually the weakest link in that chain. Centralized password vaulting, passwordless MFA, and audit trails on every account an MSP touches close a gap that contracts alone can’t.

LogMeOnce’s MSP password manager gives organizations and the providers they work with a way to:

• Vault and rotate credentials for every account an MSP accesses, instead of relying on shared logins.
• Enforce passwordless MFA on privileged accounts, matching the control that cybersecurity advisories specifically call out.
• Keep audit logs of exactly who accessed what and when, evidence you can hand an auditor or reference during a contract review.

This is a complementary control, not a replacement for managed detection or SOC services. Pair it with the vetting steps above, and check the pricing and plan comparison to see which tier fits your team size.

FAQ

What is an MSP in cybersecurity?

An MSP in cybersecurity is a third-party provider that manages ongoing security tasks like monitoring, patching, and parts of incident response on a client’s behalf. The exact scope depends on the contract, which is why written responsibility mapping matters more than the label itself.

Who are the biggest MSPs?

Market size rankings change frequently and depend on whether the list measures revenue, client count, or geographic reach, so no single, stable answer holds across sources. For procurement purposes, size matters less than whether a specific provider can document the controls and SLAs covered in this guide.

What is the difference between an MSP and an MSSP?

An MSP typically manages broad IT operations with security as one offering among many, while an MSSP specializes specifically in security monitoring, detection, and response, often running a dedicated SOC. Many organizations use both, with the MSP handling general IT and the MSSP covering deep security operations.

What is the difference between an MSP and an ISP?

An MSP manages IT systems and services like security, backups, and help desk support, while an ISP, an internet service provider, simply provides the network connection itself. The two solve different problems and are rarely interchangeable in a contract or vetting process.

How do I start vetting an MSP for information security?

Start by requesting the documentation covered in this guide: architecture diagrams, SOC runbooks, audit reports, and a written responsibility map for patching, monitoring, and incident response. CISA’s vendor assessment fact sheet offers a specific checklist to structure that first request.