Security baseline for small MSPs

Short answer: A small MSP security baseline is the minimum set of controls the team can deploy, review, prove, and explain every month without implying full compliance or incident response coverage.

Security baseline means monthly proof

A small MSP security baseline is not a certificate, a silver-bullet tool, or a promise that nothing will happen. It is the minimum operating line you can deploy, monitor, explain, and prove across managed clients without pretending you run an enterprise security program.

Use public frameworks as a map, not as decoration. The NIST Cybersecurity Framework 2.0 is useful because it separates the work into govern, identify, protect, detect, respond, and recover. For a small MSP, that should translate into simple questions: who owns the risk decision, which assets are covered, which controls are active, which alerts are reviewed, and what evidence exists this month?

If you cannot verify a control monthly, do not sell it as included.

Define the baseline before choosing tools

Tools matter, but the baseline fails earlier when scope is vague. Before you add another security product to the stack, define the control, the owner, the evidence, and the client boundary.

For each managed client, document:

• Which identity systems are in scope.
• Which endpoints are managed and which are excluded.
• Which admin accounts exist and who owns them.
• Which backup jobs are monitored and which restore paths are tested.
• Which patch categories are included in recurring service.
• Which security alerts create a ticket, a call, or an incident.
• Which controls are conditional because the client controls the system, budget, or vendor.
• Which decisions require client approval, budget, or written risk acceptance.

This connects directly to onboarding. If the client intake does not capture identity, endpoints, DNS, registrar, backup ownership, and vendor access, the security baseline starts with blind spots. Use the client onboarding checklist to make those ownership details visible before support work becomes urgent.

Start where common damage happens

CISA's small business cyber guidance and the FTC cybersecurity guidance for small businesses both push the same practical idea: handle the basics that reduce common damage before chasing advanced language. For a small MSP, that means identity, access, patching, backups, endpoint visibility, and a clear response path.

Start with these controls:

• MFA for admin accounts, remote access, and cloud identity.
• Named admin accounts instead of shared admin credentials.
• Password vaulting for privileged credentials.
• A break-glass account with controlled storage and review.
• User and vendor offboarding that removes access from identity, email, RMM, PSA, backup, documentation, and security tools.
• Endpoint protection with an assigned alert owner.
• Patch workflow for operating systems and common third-party applications.
• Backup monitoring plus a restore-path check.
• DNS, domain registrar, email, and backup ownership documented.
• Basic logging for identity and endpoint events.

The CIS Controls are a good practical reference when you need to explain why inventory, access control, audit logs, data recovery, and patching belong in the first layer. Do not turn that into a giant control spreadsheet for every small client on day one. Translate it into work your team can actually run.

Minimum baseline versus stronger baseline

Do not make one baseline do every job. A five-person accounting office, a medical office, a manufacturer with line-of-business systems, and a client with cyber insurance pressure may all need different levels of evidence.

Use a minimum baseline when the client needs recurring operational hygiene:

• Named admin access.
• MFA expectations.
• Endpoint coverage.
• Patch exceptions.
• Backup monitoring.
• Restore-path checks.
• Offboarding review.
• Monthly decision log.

Use a stronger baseline when the client has regulated data, higher downtime cost, sensitive vendor integrations, cyber insurance requirements, or leadership that expects faster incident response:

• Written risk register.
• More frequent access review.
• Stronger logging and retention.
• More formal incident escalation.
• Backup immutability or offline-copy expectations where practical.
• Regular restore tests with documented results.
• Client-facing review of open risks and accepted exceptions.

The CISA Cybersecurity Performance Goals and the CISA CPG Checklist are useful when the client wants measurable outcomes. Use them to improve consistency, not to imply that a small MSP is providing a full compliance program unless that scope is explicitly sold.

Identity and privileged access

Identity is usually the strongest first control because one weak admin account can affect many systems. The baseline should separate normal user access, named admin access, emergency access, vendor access, and MSP technician access.

The CISA advisory for managed service providers and customers is a useful reminder that MSP access can become a high-value path into client environments. A small MSP does not need complicated language to act on that risk. It needs basic discipline:

• No shared technician admin accounts.
• MFA enforced on privileged accounts.
• Admin rights granted only when needed.
• Remote access accounts reviewed monthly.
• Vendor accounts tied to a real business owner.
• Former employees and vendors removed quickly.
• Service accounts documented with owner, purpose, and rotation expectation.
• Emergency access stored separately and reviewed on a schedule.

If the client refuses MFA, refuses to remove old accounts, or wants vendors to keep permanent broad access, record the exception. That is not paperwork for its own sake. It protects the operating relationship when something goes wrong.

Endpoint, patching, and alert ownership

Endpoint coverage should be boring and visible. The baseline should answer which devices are managed, which are missing, which are stale, and which alerts have an owner.

For patching, avoid vague promises like "we keep everything updated." Use a practical rhythm:

1. Maintain a managed endpoint list.
2. Define supported operating systems and common third-party applications.
3. Patch on a recurring cadence.
4. Track failed installs and stale devices.
5. Separate emergency patching from normal patching.
6. Report exceptions in the monthly review.

This is where the tool stack selection framework matters. The right stack is not the one with the most security features. It is the one that lets your team see coverage, own alerts, act on exceptions, and explain the work without burning hours every week.

Backup and restore proof

Backups are not protected because a dashboard says green. They are protected when jobs are monitored, failures create action, protected systems are defined, and someone has checked that the restore path still works.

The CISA StopRansomware Guide emphasizes preparation, backups, and recovery as practical defenses against ransomware damage. For a small MSP, the useful translation is simple: backup status is not proof until restore expectations, failure handling, and recovery ownership are documented.

The backup restore testing checklist turns that baseline into a repeatable ticket, validation method, evidence set, and retest path.

Use a simple backup baseline:

• Identify the systems and data locations that are covered.
• Identify what is not covered.
• Monitor backup failures.
• Review protected Microsoft 365, Google Workspace, server, workstation, and line-of-business data separately when they exist.
• Test a restore path on a defined schedule.
• Keep backup admin access separate from normal user access where possible.
• Record retention, encryption, and recovery expectations in client-facing language.
• Record who approves recovery tradeoffs when speed, cost, or data loss expectations conflict.

The FTC's small business guidance points small organizations toward practical recovery preparation, including backups and response planning. For the MSP, the important part is not only having the tool. It is proving that the recovery path is not imaginary.

Client conversation and service desk boundary

Security language becomes dangerous when the client hears "covered" and the MSP means "we installed a tool." Be explicit:

• These controls are included.
• These controls are monitored.
• These controls are conditional because the client controls the system or budget.
• These items require approval as project work.
• These risks remain accepted by the client.
• These events are incidents, not normal support tickets.

This should show up in the service model. The small MSP service desk model should define which security events are handled inside recurring support, which events interrupt normal queue work, and which events need incident pricing or a separate project.

It should also show up in pricing. If the baseline adds monthly access review, backup evidence, security-alert triage, restore testing, or client risk reporting, the monthly plan must fund that work. Use the managed services pricing guide when the baseline becomes part of the recurring promise.

Accepted risk is a client decision

Small MSPs often inherit security gaps they cannot fix without budget, client cooperation, or a separate project. The mistake is carrying those gaps silently.

Record each exception with:

• The control or asset affected.
• The business owner.
• The practical risk.
• The recommended action.
• Whether it is included, project work, or out of scope.
• The date the client accepted, postponed, or rejected the action.
• The next review date.

Accepted risk does not mean the risk is safe. It means the decision is visible. If the client later changes budget, insurance requirements, or leadership expectations, the exception list becomes the starting point for paid remediation instead of an argument about memory.

The FTC Safeguards Rule guidance is a useful reminder for clients in regulated or sensitive contexts: security work often needs written programs, risk assessment, and provider oversight. Do not imply compliance unless the contract covers it, but do use that pressure to make risk decisions explicit.

Monthly evidence packet

The baseline should produce a short monthly evidence packet. It does not need to be a polished enterprise report. It needs to be clear enough that the client can make decisions and the MSP can prove the work happened. The monthly review checklist is where that evidence turns into a repeatable operating rhythm.

Include:

1. Admin accounts reviewed.
2. MFA exceptions listed.
3. Remote access exceptions listed.
4. Endpoint coverage reviewed.
5. Endpoint alerts reviewed.
6. Patch exceptions listed.
7. Backup failures reviewed.
8. Restore checks recorded.
9. Offboarding exceptions reviewed.
10. Open client decisions listed.
11. Project candidates identified.
12. Incident or security-event follow-ups separated from normal tickets.

For a small team, the first win is consistency: the same control names, the same evidence rhythm, and the same client decision log every month.

Common mistake

The common mistake is selling security language that is broader than the operating reality.

Do not claim broad protection if the monthly service only checks a few controls. Say exactly what is covered, what is monitored, what requires separate approval, and what remains outside the plan.

A small baseline that is honest, repeated, and evidenced is stronger than a large security promise that nobody can operate.

When to raise the level

Raise the baseline when the client has regulated data, cyber insurance requirements, multiple locations, frequent staff turnover, sensitive vendor integrations, or leadership that expects faster response during incidents.

Raise your own MSP process when monthly evidence takes too long to collect, alerts are ignored because they are noisy, technicians disagree on what is included, or clients repeatedly misunderstand what the recurring service covers.