Cybersecurity Checklist for MSPs: Prove 10 Core Controls

In 2026, every credible managed service provider must demonstrably enforce multi-factor authentication, run endpoint detection with staffed response, retain high-value logs, and maintain tested, isolated backups. These controls are table stakes with customers and insurers now asking for proof, not promises, alongside clear contract language about who owns which part of the defense.

TL;DR:

• Insurers commonly require evidence of MFA, staffed endpoint response, tested backups, and incident response planning before binding or renewing coverage; document these controls.
• Retain authentication, endpoint, firewall, and remote access logs for roughly six months, and aggregate them centrally so investigators can trace dormant intrusions.
• Isolate backup systems from production credentials, test full restores quarterly and partial restores monthly, and record each outcome, including failures and fixes.
• Smaller providers should enforce MFA first, document one full restore before buying broader tools, then add staffed detection and formal log retention.
• Contracts should assign hardening, detection, incident response, and backup testing to named parties for each system, avoiding vague promises that can trigger disputes.

1. At-a-glance checklist: the 10 core MSP cybersecurity practices

Before diving into specifics, use this as a working audit. Each item below pairs a control with the question a customer, auditor, or insurer will actually ask.

1. MFA everywhere – When did every privileged and remote-access account last confirm MFA enrollment?
2. EDR plus staffed response – Who reviews an EDR alert at 2 a.m., and how fast?
3. Centralized logging – Are logs retained for roughly six months, as CISA and partner agencies recommend?
4. Tested backups – When did you last complete a full restore, not just a backup job?
5. Least privilege – Do admin accounts expire or require elevation requests?
6. Patch prioritization – Are known exploited vulnerabilities patched first?
7. Segmented remote access – Can one compromised MSP account reach every client network?
8. Clear contracts – Does the contract state who detects, who responds, who restores?
9. Incident response plan – Has it been tested in the last twelve months?
10. Security awareness training – Are phishing simulation failures tracked and retrained?

Insurers commonly ask for evidence on items 1, 2, 4, and 9 before binding or renewing a policy. Treat those four as non-negotiable baseline documentation, not optional extras.

2. Identity and privileged access: enforce MFA, tier admin accounts, and use password management

Identity is the front door, and for MSPs it is a door that opens into every client network at once. The joint advisory from CISA and international partners names MFA enforcement on MSP accounts as one of the first tactical actions a provider should take, precisely because a single stolen credential can cascade across dozens of customers.

Enforce MFA on every account that touches a customer environment: remote monitoring and management tools, ticketing systems, cloud consoles, and any shared service account. No exceptions for legacy integrations or “temporary” access.

• Require MFA on all privileged and MSP-to-client accounts, not just the primary admin login.
• Build admin tiering so day-to-day support staff use standard accounts, with elevation requested and time-limited for sensitive tasks.
• Centralize secrets and service-account credentials in a dedicated password manager instead of spreadsheets or shared documents.
• Rotate shared credentials on a fixed schedule and immediately after any staff departure.
• Query authentication logs regularly to confirm no technician is reusing one credential set across multiple client tenants.

Admin tiering sounds bureaucratic until you picture the alternative: a single compromised technician laptop with standing access to every client’s domain controller. Time-limited elevation, where a technician requests higher privileges for a defined task and window, closes that gap without slowing down routine work.

A centralized credential vault built for MSP use, such as our MSP password manager, also gives you an audit trail: who accessed which client’s credentials, when, and for how long. That record becomes useful evidence later, both for internal review and for client-facing attestation.

Pro Tip: Run a quarterly query that cross-references technician login sessions against client tenant boundaries, any account appearing in two tenants within the same session window deserves a closer look.

3. Endpoint security and detection: deploy EDR and back it with MDR or staffed response

Endpoint detection and response tools generate alerts. Alerts without a human reviewing them in real time are just noise, and that gap is where ransomware operators live. CISA’s guidance for MSPs lists robust endpoint monitoring alongside least privilege and tested backups as core mitigations, and the “robust” part depends on who is watching, not just what is installed.

Deploy EDR across every endpoint and server you manage, and feed that telemetry into a central view rather than leaving it siloed tool by tool.

• Install EDR on all endpoints and servers, including infrastructure devices often skipped during rollout.
• Integrate EDR telemetry into one centralized console instead of per-client silos.
• Contract for or staff 24/7 MDR or SOC coverage so alerts get triaged outside business hours.
• Define and track mean time to acknowledge and mean time to respond as internal KPIs.
• Tune detection rules regularly to cut false positives before they cause analyst fatigue.

Alert volume without human review tends to produce the same outcome: real intrusions buried under noise, which is why national guidance pairs monitoring tools with staffed response rather than treating detection software as sufficient on its own. The fix practitioners point to is consistent: tuned alerting plus a defined triage workflow, so every alert has an owner and a clock running against it.

Mean time to acknowledge and mean time to respond are worth tracking even if you run response in-house. If your MTTA creeps past fifteen minutes during business hours, or hours overnight, that is a staffing gap before it becomes a breach report.

4. Monitoring, logging, and SIEM: aggregate logs, retain them, and tune alerts

Detection depends on evidence existing somewhere you can actually search it. The joint advisory from CISA and partner cybersecurity authorities recommends retaining high-value logs for at least six months, a window long enough to catch intrusions that sit dormant before an attacker moves laterally.

Centralizing logs into a SIEM or log aggregation platform turns scattered data into something searchable during an actual incident, when minutes matter.

• Aggregate logs from authentication systems, EDR, firewalls, and remote access tools into one platform.
• Retain high-value logs for roughly six months, matching the baseline national guidance recommends.
• Normalize log formats across different client environments so searches work consistently.
• Set a recurring review schedule, not just alert-driven checks, to catch patterns automated rules miss.
• Flag repeated failed authentication attempts immediately following a password reset as a specific watch condition.

That last point is worth calling out on its own. A burst of failed logins right after a credential change often signals an attacker testing stolen or guessed replacement passwords, and it is cheap to automate as a standing alert.

Pro Tip: Schedule a monthly fifteen-minute log review focused only on authentication anomalies, a short recurring habit catches what a six-month archive sitting untouched never will.

5. Patch and asset management: prioritize, verify, and report

You cannot patch what you do not know you have, and you cannot patch everything at once with the same urgency. CISA’s Insights guidance for MSPs places patching and asset visibility alongside least privilege and backups as a core mitigation set, and the sequencing matters as much as the coverage.

• Maintain a current asset inventory across every client environment, including shadow IT and forgotten appliances.
• Prioritize patches for vulnerabilities listed in CISA’s Known Exploited Vulnerabilities catalog before working through the general backlog.
• Automate deployment where testing allows, and document exceptions with a reason and a remediation timeline.
• Generate patch compliance reports per client on a fixed schedule, not only when something breaks.
• Treat unpatched internet-facing systems as priority one regardless of severity score alone.

Patch reports and vulnerability scan results double as evidence. When a client or an insurer asks “how do you know your environments are current,” a dated report answers the question faster than a verbal assurance ever will.

6. Backups and recovery: isolated backups, frequent tests, and documented restores

A backup job that completes successfully tells you almost nothing about whether recovery will work. Industry practitioners consistently flag this gap: plenty of MSPs have backup jobs running, far fewer have proof that a full restore actually works under pressure.

1. Isolate backups from production, either air-gapped or logically separated, with encryption keys stored apart from the backup system itself.
2. Test full restores quarterly for each client environment, not just spot-check a handful of files.
3. Test partial restores monthly to catch configuration drift between full-restore cycles.
4. Document every test with timestamps, scope, and outcome, success or failure both get recorded.
5. Share restore evidence in client-facing reporting so customers see proof, not just a line item on an invoice.

Air-gapping matters because ransomware increasingly targets backup infrastructure first, specifically to eliminate the recovery option before encrypting production data. A backup reachable from the same credentials as production is not meaningfully isolated.

Pro Tip: Keep a simple restore log, date, client, system, and result, and treat a missed quarterly test the same way you would treat a missed patch cycle: as an open risk item, not an administrative footnote.

7. Secure remote access and network segmentation: dedicated connections and least exposure

The tools that make MSP operations efficient, centralized remote access, shared credentials, broad standing permissions, are the same ones attackers target first, because one compromised connection point can reach every managed client at once. CISA’s joint advisory specifically calls out dedicated connections and network segmentation as tactical steps to limit that blast radius.

• Use dedicated VPNs or zero-trust remote access specifically for MSP operations, separate from general client-facing access.
• Segment management networks so a compromised jump box cannot reach unrelated systems or other clients.
• Restrict MSP accounts to only the systems they are contracted to manage, not broad administrative reach by default.
• Audit trust relationships between your infrastructure and each client environment on a recurring basis.
• Eliminate any standing credential that grants access across more than one client tenant.

The goal is containment. If one client’s environment is compromised, segmentation decides whether that stays a single-client incident or becomes a multi-tenant breach notification spanning your entire book of business.

8. Governance, contracts, and supply-chain risk: clarify responsibilities and vet vendors

Ambiguity in a contract becomes a dispute during an incident, right when clarity matters most. CISA’s joint advisory specifically recommends that MSPs and customers make security responsibilities explicit in writing, because “the MSP handles security” is not a specific enough commitment when a breach notification deadline is ticking.

• Spell out in contracts exactly who owns hardening, detection, incident response, and backup testing for each system.
• Require subcontractors and software vendors to meet a documented baseline of security controls before integration.
• Assess supplier criticality: a scheduling tool failing is different from an RMM platform failing.
• Maintain a vulnerability disclosure process so vendors and researchers can report issues responsibly, as our own policy outlines.
• Use NIST CSF Tiers to describe current maturity versus target maturity in plain language clients can understand.

NIST CSF 2.0 structures this conversation well: its Tiers run from Partial to Adaptive, giving you a shared vocabulary for “here is where we are, here is where we are committing to be” instead of vague reassurances.

9. Incident response, exercises, and reporting: plan, practice, and prove it

A written incident response plan that has never been exercised is a document, not a capability. The gap shows up exactly when it matters least to discover it, mid-breach.

1. Maintain a written IR plan covering detection, containment, eradication, and recovery steps specific to MSP operations.
2. Run tabletop exercises at least twice a year, walking through a realistic scenario like ransomware hitting a shared RMM tool.
3. Run live restore exercises tied to the backup testing cadence, so recovery claims are proven, not assumed.
4. Document notification and escalation steps, including which clients get notified, by whom, and within what window.
5. Prepare attestation artifacts, tabletop summaries, restore logs, and response timelines, ready to hand to an insurer or client auditor on request.

These exercises do double duty. They sharpen your actual response speed, and they produce the paper trail that insurers and enterprise clients increasingly require before binding coverage or signing a contract.

Pro Tip: After every tabletop exercise, write down one thing that broke the scenario, a missing contact, an unclear escalation step, and fix that specific gap before the next exercise instead of starting over with a generic checklist.

10. People, training, and operational resilience: security awareness and staffing to avoid burnout

Technical controls fail quietly when the people operating them are stretched thin or undertrained. Both failure modes are preventable with the same basic discipline you apply to patching or backups: measure, track, fix.

• Run phishing simulations on a recurring schedule, role-based where possible, since a billing clerk and a network engineer face different lures.
• Track simulation failure rates per employee and require targeted retraining rather than a one-size-fits-all annual course.
• Build staffing schedules with margin for incident response, not lean rotations that assume nothing will go wrong during a holiday weekend.
• Document standard operating checklists for common tasks so coverage gaps do not translate into skipped steps.
• Report awareness metrics, phishing simulation pass rates, training completion, to clients as part of regular security reporting.

Burnout is a security control gap, not just an HR issue. An exhausted on-call technician misses alerts the same way an untuned detection rule does, and staffing margin is one of the cheapest mitigations available against that specific failure mode.

11. Operational maturity checklist and how to demonstrate it to customers and insurers

Controls that exist only as claims do not satisfy an insurance underwriter or a client’s procurement team anymore. What satisfies them is a short, specific evidence packet you can hand over without scrambling.

• Restore test records: dated logs showing full and partial restore results, including at least one documented failure and fix.
• MDR or SOC SLAs: the contracted mean time to acknowledge and respond, in writing, not verbal assurance.
• Log retention manifests: confirmation that high-value logs are held for roughly six months, matching CISA’s joint advisory baseline.
• Patch and vulnerability reports: scan results showing known exploited vulnerabilities addressed first.
• IR exercise summaries: tabletop and live-restore results from the last twelve months.

A small set of verifiable artifacts, restore logs, MDR tickets, patch reports, and retention manifests, reduces ambiguity during audits and insurance renewals far more than a longer feature list does. Map each artifact to a NIST CSF 2.0 function, Identify, Protect, Detect, Respond, Recover, and you get a Current Profile versus Target Profile that insurers and enterprise clients can read in minutes instead of a thirty-page narrative.

Why operational discipline matters more than product shopping

The MSP cybersecurity conversation spends too much time on which tool to buy and not enough on whether anyone can prove the tool works. A restore test that has actually been run, with a timestamp and a documented outcome, tells a client more than any vendor comparison chart.

That is not an argument against good tools, it is an argument for treating operational proof as the real deliverable. An EDR license means little if the alerts it generates sit unread at 3 a.m. A backup job means little if nobody has confirmed the restore completes intact.

For smaller MSPs without a security team sitting idle, the honest prioritization path starts narrow: enforce MFA everywhere first, because it is the highest-leverage, lowest-cost control available. Then get one full restore test documented, even manually, before investing in broader tooling. Staffed detection and formal log retention can follow once those two fundamentals are provably in place, not before.

Clients and insurers are asking harder questions than they did a few years ago, and the MSPs who answer with evidence instead of assurances are the ones keeping contracts and renewing coverage.

— Mike

How LogMeOnce helps MSPs meet identity, MFA, and attestation needs

Every control covered above depends on identity being locked down first, and that is exactly where we built our tools to fit. Our MSP password manager gives you centralized credential storage for client environments, with audit logs that double as the evidence artifacts insurers and auditors ask for.

Specific ways our platform supports the practices in this playbook:

• Centralized credential vaulting for service accounts, replacing shared spreadsheets with an auditable, rotation-ready system.
• Passwordless MFA deployment across privileged and remote-access accounts, covering the enforcement gap most advisories flag first through our passwordless MFA product.
• Dark web monitoring that flags exposed client or staff credentials before attackers can use them, through our identity theft protection and dark web scan.
• Access logs and session records you can export directly into the attestation packet a client or insurer requests.

If you manage credentials across multiple client tenants today, compare plans on our pricing and comparison page and see which tier fits your technician count and client load.

FAQ

What is the minimum MFA coverage an MSP needs in 2026?

Every account that touches a customer environment needs MFA, including remote monitoring tools, ticketing systems, and shared service accounts, not just the primary administrator login. CISA’s joint advisory names this as one of the first tactical steps MSPs should take.

How long should MSPs retain security logs?

National guidance recommends retaining high-value logs for roughly six months, a window long enough to catch intrusions that stay dormant before moving laterally, according to joint CISA guidance. Logs should cover authentication, EDR, firewall, and remote access systems at minimum.

How often should an MSP test backup restores?

A practical cadence is a full restore test quarterly per client environment and a partial restore test monthly to catch configuration drift between full cycles. The test itself matters less than documenting the result, since a backup job completing successfully does not confirm the restore will work.

What should an MSP’s contract say about security responsibilities?

Contracts should spell out exactly who owns hardening, detection, incident response, and backup testing for each system, since vague responsibility language creates disputes during an actual incident. This clarity is specifically recommended in CISA’s joint advisory for MSPs.

How can an MSP demonstrate security maturity to insurers?

A short evidence packet works best: restore test records, MDR or SOC response time SLAs, log retention manifests, and incident response exercise summaries from the past twelve months. Mapping these artifacts to NIST CSF 2.0 functions gives insurers a concise current-versus-target maturity picture.

Sources

• Protecting Against Cyber Threats to Managed Service Providers and their Customers (CISA joint advisory)
• NIST Cybersecurity Framework (CSF) 2.0 implementation guidance