By Dan Stark, SEO & Content Strategy Contributor, CTMS
You’re comparing two cybersecurity proposals. Both list endpoint protection, multifactor authentication, monitoring, and backups. One costs more.
Look at the work behind each line item. Who investigates an alert at 2 a.m.? Who fixes a failed security update? Who checks that a backup can actually be restored? Until the proposals answer those questions, the prices aren’t comparable.
When evaluating cybersecurity services for small businesses, require clear scope, included work, responsible parties, evidence, review schedules, exclusions, and escalation terms. Get those answers into the documents that define the service.
That gives you a basis for comparing managed cybersecurity services by the work each provider commits to perform.
Start with what the proposal actually covers
Make sure both providers are pricing the same environment.
List the locations, users, devices, cloud accounts, applications, and business systems you expect them to support. Flag anything with a separate owner, such as a software vendor or your internal IT team. Ask each provider to document its assumptions and exclusions.
A proposal covering employee laptops may exclude servers. Microsoft 365 work may cover one tenant while an acquired company’s environment requires a separate project. A backup service may cover files without covering the applications you need to use them.
An exclusion can be reasonable. It still needs an owner and a plan before you sign.
Use the same seven questions for every service
For each major service in the proposal, record these answers:
| Question | What you need in writing |
|---|---|
| What is covered? | Systems, accounts, locations, and risks inside the scope. |
| What work is included? | Setup, ongoing operation, checks, corrective work, and separately priced work. |
| Who is responsible? | Provider, internal team, relevant vendors, and people authorized to approve changes. |
| What evidence will we receive? | Reports, test results, ticket records, or other outputs documenting the agreed work. |
| When does the work happen? | Coverage hours, review frequency, reporting schedule, and event-triggered work. |
| What is excluded? | Unsupported systems, limits, dependencies, and additional charges. |
| What happens when something fails? | Escalation contacts, authority to act, communication, and fallback arrangements. |
NIST’s Cybersecurity Framework 2.0 calls for establishing supplier responsibilities, incorporating security requirements into agreements, and conducting due diligence before a relationship begins. These seven questions are a practical buying worksheet, not a NIST compliance standard.
For example, a proposal says “patching is included.” Ask: “If an update fails on a covered server, who investigates it, is corrective work included, who approves downtime, and where will we see the issue until it’s closed?” That turns a feature label into a service commitment you can evaluate.
Ask for the right evidence at the right stage
Redacted sample reports, example tickets, and escalation workflows illustrate a provider’s proposed process. They don’t prove execution, staffing, or the condition of your systems.
An authorized assessment can produce evidence about your environment before you sign an ongoing service agreement. Agree on its outputs, timing, and cost, then define what onboarding and ongoing service will produce. Decide how newly discovered gaps will affect scope and pricing.
| Service area | Clarify before signing | Client-specific evidence to require in scope |
|---|---|---|
| Identity and access | Which accounts and applications are included? Who manages exceptions and administrator access? | Coverage summary, documented exceptions, and access-review findings. |
| Endpoint protection | Who deploys protection, checks coverage and health, and corrects gaps? | Expected devices reconciled against enrolled devices and reporting health, with exceptions and owners. |
| Patching | Which systems and applications are covered? Who handles failures and approves downtime? | Missing or failed updates, exceptions, and corrective actions. |
| Monitoring and response | Who reviews alerts, during which hours, and with what authority? | For incidents that occur, investigation, action, escalation, and closure records. |
| Backup and recovery | Which data and systems are covered? Are restore tests and recovery labor included? | Backup exceptions and restore-test results identifying scope, outcomes, and unresolved issues. |
| Reporting | Who reviews findings with leadership and follows up? | Open risks, assigned actions, due dates, and progress. |
You don’t need another client’s confidential information to understand the proposed reporting. Request redacted examples or blank formats, then agree on a secure process for sharing your own evidence.
The FTC’s vendor-security guidance recommends documenting security expectations in contracts and verifying that vendors meet them.
Resolve three phrases that can hide different services
“Monitoring is included”
Have the provider walk through an alert arriving outside your business hours. Which systems generate alerts? Who reviews them? Can that person investigate and take agreed containment action, or only forward the alert? Who contacts your business, and what happens if the first contact doesn’t answer?
Keep the monitoring window separate from the reporting schedule. A monthly report doesn’t tell you who handles an alert overnight.
Separate acknowledgment, investigation, and response, too. If the agreement includes time targets, define what starts and stops each clock.
“MFA is enabled”
Multifactor authentication adds protection to account access. The proposal still needs to define the accounts and applications being managed.
Ask about employees, administrators, outside users, and applications requiring different controls. Have the provider explain how service identities and emergency access are handled. Define who approves exceptions, how they’re documented, and when they’re reviewed.
A coverage percentage needs a denominator. Which accounts were counted, and what was excluded?
For a deeper review of enforcement, administrator access, and exceptions, use CTMS’s guide to Microsoft 365 security management.
“Backups are successful”
A successful backup job reports completion of its configured tasks. A restore test validates the particular data or system tested against defined criteria. Neither alone proves that the whole business can recover.
Agree on test scope, frequency, success criteria, included labor, and who addresses failures. Records should identify what was tested, when, the outcome, and unresolved issues. Define recovery objectives and the assumptions behind them.
NIST’s incident-response guidance includes testing backups, checking restoration assets, and validating recovered systems. It doesn’t establish a universal test schedule or guarantee recovery within a particular time.
Clarify the backup and disaster recovery responsibilities: who coordinates with the security team, authorizes restoration, restores systems, and confirms the business can use them again?
A successful test of one folder shouldn’t be presented as proof of complete business recovery.
Make room for exceptions and corrective work
A useful security report shows what still needs attention.
Microsoft’s Defender sensor-health guidance illustrates why context matters. An inactive device may be unused or offboarded, or it may have stopped reporting. Inactivity needs review against the device’s expected state. Misconfiguration requires investigation and correction.
Coverage reporting should define the expected device population and reconcile exceptions. A device’s presence in an inventory doesn’t establish that its protection is working as expected.
When a check reveals a gap, is correction included? Who owns it? Who approves any cost or disruption? How does the issue remain visible until it’s resolved or a business decision is recorded?
If you’re using managed IT alongside your internal team, shared responsibility should identify each party’s tasks and the person coordinating the handoff.
Get the boundaries into the agreement
Service details may sit in the proposal, statement of work, service description, or referenced master agreement. Read them together. Limits in one document can narrow what another appears to include.
Check whether forensic investigation, specialist incident response, on-site assistance, infrastructure rebuilding, and application recovery are included or separately priced. Identify after-hours charges and any approval requirements.
Your business needs an internal decision-maker to approve spending, prioritize disrupted operations, authorize changes, and coordinate with legal or insurance contacts. The provider’s technical scope doesn’t establish insurance coverage or guarantee compliance.
Clarify exit terms, too: access removal, documentation handover, data return or deletion, and transition charges. NIST’s framework includes planning for the end of supplier relationships.
Compare the unresolved work before comparing the price
Fill in the worksheet from each written proposal. Mark unclear answers as unresolved and work through them with the provider. A blank answer is a question to settle, not proof that the provider can’t do the work.
Put material commitments into the final scope documents. Then compare the total arrangement: provider responsibilities, work your business retains, outside specialists, and additional charges.
You should be able to explain who does the work, how you’ll see that it happened, and what happens when something needs attention.
To discuss the right scope for your business, talk with CTMS about your security requirements.
