Category: MSP Resources

  • How to Use External Recon Data as a Cold Outreach Tool for MSP Prospecting

    Most MSP cold outreach is indistinguishable from noise. A sequence of emails about how you have been helping businesses like theirs with IT and security. A LinkedIn message asking if they have considered upgrading their cybersecurity posture. A cold call that opens with “how are you handling your IT today.” None of it gives the prospect a reason to respond, because none of it demonstrates that you know anything specific about their situation — which means they have no reason to believe you can help with it.

    External recon data changes this equation. Before you send a single message, you can know things about a prospect’s environment that are both specific and actionable: whether their email domain is missing DMARC policy, whether their SSL certificate is expiring or using a deprecated cipher, whether executive email addresses have appeared in breach datasets, whether they are running services on ports visible to the public internet that suggest an unpatched infrastructure. That data is not obtained through any unauthorized access — it is what any external party, including a threat actor, can see about their organization without credentials.

    Using that data in outreach — correctly — turns a cold contact into a professional peer sharing actionable intelligence. Using it incorrectly turns a cold contact into something that reads like a threat, a gotcha, or an intrusion. The difference is almost entirely in framing.

    What External Recon Data Actually Tells You

    The categories of externally visible data most useful for MSP prospecting fall into five areas, each of which suggests a different conversation opener and a different compliance or business risk angle.

    Email authentication posture. SPF, DKIM, and DMARC records are publicly queryable DNS records that tell you whether an organization has implemented email authentication controls. A missing or misconfigured DMARC record means the domain can be spoofed — an attacker can send email that appears to come from the organization’s exact domain with no technical barrier. This finding is relevant to HIPAA (information integrity), CMMC (configuration management), PCI DSS (authentication requirements), and basic cyber insurance underwriting. It is also extremely common: the majority of SMB domains have either no DMARC record or a DMARC record in monitoring mode rather than enforcement, which provides zero protection against spoofing.

    SSL certificate condition. SSL certificate expiry, weak cipher suites, and mixed-content configurations are externally visible. An expired or soon-to-expire SSL certificate means the organization’s website will generate browser warnings — a visible customer-facing failure that most decision-makers care about immediately. Weak cipher suites are more relevant for compliance-obligated clients: PCI DSS 4.0 has explicit requirements around deprecated TLS versions, and a client running TLS 1.0 or 1.1 on their payment-facing application is out of compliance.

    Credential breach exposure. Dark web breach datasets contain email addresses from known data breaches across thousands of services. An executive or employee whose email address appears in breach data has had credentials exposed — potentially including passwords that are being reused on corporate accounts. For compliance-obligated clients, this is direct evidence of the kind of credential exposure that leads to business email compromise, and it is the type of specific, named finding that makes an outreach message feel like intelligence rather than a pitch.

    Exposed services and open ports. Shodan and SecurityTrails index publicly visible services and open ports across the internet. An organization with RDP, SMB, or administrative interfaces exposed to the public internet without appropriate access controls is running a configuration that is directly targeted by automated scanning tools within minutes of exposure. For regulated clients, an exposed administrative service is an access control finding that maps directly to CMMC, HIPAA, and NIST CSF requirements. For any client, it is a concrete, specific vulnerability you can reference before any engagement begins.

    HTTP security headers. HTTP security header configuration — Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, and others — is visible in any web server response. Missing or misconfigured security headers are relevant to web application compliance requirements under PCI DSS 4.0 and are a standard finding in web application security assessments. For a client who handles payments or sensitive data through a web interface, missing headers are a low-cost, high-visibility finding that demonstrates awareness of their specific environment.

    → The free security tools page provides purpose-built checks across all of these categories — external vulnerability scan, dark web breach check, SSL analyzer, SPF/DKIM/DMARC checker, DNS security audit, HTTP security headers check, and a security posture scorecard — without requiring any internal access to the prospect’s environment.

    What to Say — and What Not to Say

    The frame that works: you ran a check, you found something specific, you wanted to share it because it is relevant to the prospect’s situation, and you are offering a short conversation to walk through what you found and what it means. Professional, peer-level, non-threatening.

    The frame that does not work: you found a vulnerability, they are at risk, you can fix it if they call you now. This reads as a scare tactic whether it is intended as one or not, and it immediately positions you as someone trying to close a deal rather than someone trying to help. Sophisticated buyers — the ones you want — will not respond to it, and the ones who do will often be the ones most likely to cancel when the urgency wears off.

    Specific things to avoid:

    • Do not say “your network has vulnerabilities” — this is vague and sounds like a threat.
    • Do not say “we found serious security issues with your systems” — “serious” is a judgment that belongs after the conversation, not in the opening line.
    • Do not send a long list of findings in the cold message — one specific, relevant finding is more effective than ten findings that feel like a report no one asked for.
    • Do not frame the check as something you do to everybody — frame it as something you did because they are a prospect you are reaching out to. It should feel like a professional courtesy, not a form letter with a mail-merge variable.
    • Do not lead with the worst finding you found — lead with the most relevant one to their compliance or business situation.

    What does work:

    • One specific finding, stated in plain English, connected to a business or compliance consequence the prospect recognizes.
    • An offer to walk through the full results — not a demand for a meeting, but an invitation to a conversation that has something concrete to discuss.
    • A short, specific call-to-action: fifteen or twenty minutes, on a named day or two, to walk through the findings together.
    • A tone that reads like a peer sharing information they thought was worth passing along — not a vendor trying to qualify a lead.

    Three Outreach Angles That Work in Practice

    Angle 1 — Email authentication and business email compromise risk

    Best for: Any organization that sends invoices, contracts, or client communications by email. Healthcare practices, legal firms, financial advisors, defense contractors. Universally applicable, high relevance regardless of compliance framework.

    The finding: DMARC record is missing or set to p=none (monitoring only, no enforcement). The domain can be spoofed.

    The opener: “I ran a quick check on [domain.com]’s email authentication settings before reaching out. Your DMARC record is currently set to monitoring only, which means someone could send email that appears to come from your exact domain — your clients would see it as coming from you with no technical indicator that it is fraudulent. It is a straightforward fix, but I wanted to flag it before reaching out. Happy to walk through the full check if you have fifteen minutes — are you free [day] or [day]?”

    Why it works: The prospect immediately recognizes the business consequence — their clients receiving fraudulent invoices that look exactly like theirs. It does not require any security background to understand why that is bad. The fix is concrete and achievable, which prevents the response of “that sounds like a lot of work.” The opening checks — and the offer to share the full results — frame the relationship as one where you are already doing work on their behalf before they have agreed to anything.

    Angle 2 — Credential breach exposure

    Best for: Organizations where a named executive or a significant number of employees appear in breach datasets. Healthcare, legal, financial — any environment where a compromised credential reaching regulated data is a reportable event.

    The finding: One or more email addresses from the domain appear in known breach datasets.

    The opener: “I ran a dark web breach check on [company name]’s domain before reaching out — [X] email addresses from your organization appear in known breach datasets. That does not necessarily mean those accounts have been compromised, but it means those credentials have been exposed in some context. For a [healthcare practice / defense contractor / financial firm], that is the kind of finding worth knowing about before an auditor or an insurer asks about it. Happy to share the full results and walk through what they mean — do you have twenty minutes this week?”

    Why it works: Naming the count without naming the specific addresses strikes the right balance — it is specific enough to be credible but does not feel like you are publishing their employees’ personal information in a cold email. The compliance angle — an auditor or insurer asking about it — grounds the conversation in external pressure rather than hypothetical risk. The offer to share the full results creates a reason to get on the call.

    Angle 3 — Exposed services for compliance-obligated clients

    Best for: Defense contractors, manufacturing firms, healthcare IT environments — any organization where externally visible administrative services represent a direct compliance finding rather than just a theoretical risk.

    The finding: RDP, SMB, or an administrative console visible on a public-facing IP associated with the organization’s domain.

    The opener: “I ran an external scan on [company name]’s public IP range before reaching out — there are a few services visible from the internet that caught my attention, including [service name] on [port], which is the kind of thing that shows up as a direct finding in a CMMC assessment. I did not go beyond what any external party can see, but I wanted to flag it. If you have fifteen minutes, I can walk through the full scan results and what they would look like in a formal compliance review — are you available [day]?”

    Why it works: The explicit statement that you did not go beyond what any external party can see is important — it preempts the “how did you access our systems” question that this type of outreach sometimes triggers. Naming the specific service and port is more credible than a vague reference to “issues we found.” The compliance consequence — this shows up in a CMMC assessment — immediately reframes the finding as a business risk rather than a technical detail.

    How to Move From a Finding to a Booked Call

    The cold message gets a response. Now what?

    The goal of the first response is not to sell anything. It is to get to a twenty-minute call where you share the full results, confirm their compliance situation, and determine whether there is a gap you can help close. Everything before that call is setup. Do not try to close anything in email.

    When a prospect responds — even if the response is skeptical or asking what you found — the reply has one job: make it easy to get to the call. “Happy to send you the full report — I can also walk through it with you, which makes it easier to ask questions about specific items. Do you have fifteen minutes on [day] at [time], or [alternative]?” Two specific time options, not a link to a calendar. Options are easier to respond to than open-ended scheduling requests.

    On the call itself, the structure that moves toward a discovery engagement rather than a dead end has three parts. First, walk through the external findings — share the screen if you can, present the report, let the prospect see exactly what you found and exactly how you found it. This transparency about the process removes any residual concern about how you obtained the data. Second, ask the compliance question: “Are you under any specific compliance obligations — CMMC, HIPAA, cyber insurance requirements — where these findings would be relevant?” The answer tells you the scope and urgency of the engagement. Third, close to next step: “Based on what we found externally, I would want to run a fuller internal assessment to see how this compares to what is happening inside the network. Would you be open to scheduling that?”

    The self-assessment is a useful bridge between the external findings conversation and the fuller internal engagement. A prospect who has just seen their external posture score and heard the compliance implications is primed to spend five minutes on the self-assessment — which generates a branded report that covers both external and self-reported internal posture, gives them something concrete to share internally, and gives you a second data point to reference in the follow-up.

    The Workflow in Practice: Five Prospects Per Week

    Here is what a realistic, sustainable external recon prospecting workflow looks like at the individual account manager level. The goal is not volume for its own sake — it is a repeatable process that produces quality first contacts with specific, evidence-backed openers.

    Monday: Identify five target companies in your compliance vertical — defense contractors, healthcare practices, whatever your primary segment is. Pull their domains. Run the external check suite on each: SPF/DKIM/DMARC, SSL, dark web breach, HTTP headers. Takes about twenty minutes total with purpose-built tooling.

    Monday–Tuesday: Review the results for each target and identify the single most relevant finding for each one — the finding most likely to resonate based on their industry and probable compliance obligations. Write a personalized opener for each using the frameworks above. Send.

    Wednesday: Follow up on any non-responses with the day-two touchpoint referencing a second finding from the check. Keep it to one sentence plus a call to action.

    Thursday–Friday: Take any response conversations to calls. For non-responses after two touches, move them to a longer-cycle compliance deadline nurture sequence rather than continuing to cold-message.

    At five per week, fifty weeks per year, that is 250 targeted, evidence-backed cold contacts annually — each of which has a specific, documented finding attached to it rather than a generic security pitch. The response rate on specific, finding-anchored outreach is consistently higher than generic security messaging, and the quality of the conversations that result is better because the prospect already knows what you found before they agree to talk.

    To see how SentinelCommand supports security assessments, compliance mapping and reporting, book a demo.

    → Book a Demo

    Frequently Asked Questions

    Is it legal to run external scans on a prospect’s domain before engaging them?

    The checks described in this article — DNS record queries, SSL certificate inspection, HTTP header checks, dark web breach database lookups, and passive OSINT through tools like Shodan — all operate on publicly available information. They do not require credentials, do not involve accessing internal systems, and do not exceed what any external party can see about an organization’s public-facing infrastructure. This is fundamentally different from active network scanning that probes internal systems or bypasses access controls. The legal and ethical line is between passive observation of publicly visible information and active intrusion into systems you are not authorized to access. Everything in this article stays firmly on the passive observation side. When in doubt, consult your legal counsel on what is appropriate in your jurisdiction and for your specific tooling.

    How do I handle the prospect who asks “how did you get this information?”

    Answer directly and without defensiveness: “All of this data is publicly visible — it is what any external party, including a threat actor, can see about your organization without any credentials or special access. We run these checks on every prospect we reach out to as a courtesy — it helps us make sure the conversation is relevant to what you are actually facing.” That answer is transparent, accurate, and reframes the question from “did you do something unauthorized” to “oh, this is information that is visible to everyone.” Most prospects find the latter more concerning than the former.

    What if the external check turns up nothing significant?

    First, that is relatively rare — most SMB domains have at least one of the common findings. Second, a clean external check is itself a useful data point: it tells you the prospect has done some basic hygiene on their perimeter, which means the more interesting conversation is about whether their internal controls and compliance posture match their external appearance. “Your external posture is cleaner than most companies your size — which usually means the gaps are internal. We have found that externally clean environments often have significant AD or cloud identity issues that are not visible from outside. Would you be open to a conversation about what an internal review would show?” That is a different opener, but it still leads to a qualified conversation.

    How do I avoid sounding like a threat actor in my outreach?

    Three things: identify yourself and your company clearly in the first sentence, explain the professional context for the check before stating the finding, and offer to share rather than withhold. “We found serious vulnerabilities in your network” sounds threatening because it withholds specifics and implies leverage. “I ran a quick external check before reaching out — [specific finding] came back, which I wanted to flag” sounds like professional due diligence because it is transparent about what you did and why. The distinction is between demonstrating knowledge and implying threat. Everything in the framing guidance in this article is designed to stay on the right side of that line.

    Should I send the full report in the cold email or save it for the call?

    Save the full report for the call, or offer to send it in exchange for the meeting. Attaching a full scan report to a cold email — especially from an unknown sender — is likely to trigger spam filters, is likely to be ignored if it arrives, and removes the primary incentive for the prospect to get on a call with you. The cold message should reference one specific finding and offer to walk through the rest. “I have the full results if you want to go through them” is a reason to schedule a call. A PDF attachment to an unsolicited email is something someone closes without reading.

    How do I scale this without it becoming a copy-paste process that loses the personalization?

    The personalization is in the finding, not the prose. The message template can be largely consistent — the opener, the offer, the call to action. What is personalized is the specific finding you lead with, the compliance framework you reference based on their industry, and any other context you have from research (recent contract wins, changes in leadership, new regulatory announcements in their sector). A well-structured template with one personalized finding reference per prospect reads as specific even if the surrounding language is standardized. The goal is not to rewrite every word — it is to ensure that the prospect cannot look at the email and reasonably conclude that it was sent to a thousand people at once.

  • The Default Entra Settings That Are Putting Your Clients at Risk Right Now

    Microsoft ships Entra ID — formerly Azure Active Directory — with default settings designed to balance usability and security for the broadest possible range of organizations. For an enterprise with a dedicated security team and a mature identity governance program, those defaults are a starting point that gets customized before the tenant goes into production. For most of the regulated SMBs your clients are, those defaults may still be in place months or years after the tenant was first configured — and some of them represent significant security gaps.

    This is not a theoretical problem. Identity-based attacks are consistently the leading cause of cloud security incidents. Business email compromise through compromised Microsoft 365 credentials, unauthorized access to Azure resources through overprivileged service accounts, lateral movement through guest account relationships — these are not advanced nation-state techniques. They exploit configurations that many organizations accept because no one ever reviewed them against a security baseline.

    As the MSP responsible for these environments, a structured Entra ID security review is both a defensible security service and a direct contribution to your clients’ compliance posture. CMMC, HIPAA, PCI DSS, SOC 2, and NIST CSF all have controls that map to identity and access management. The gaps this article describes are not just technical issues — they are compliance evidence gaps.

    Why Default Settings Are a Recurring Problem, Not a One-Time Fix

    The standard advice is to review your Entra configuration once and harden it against a baseline. That advice misses the fundamental challenge of cloud identity environments: they drift. Settings change when someone in IT solves a ticket by relaxing a policy. Guest accounts accumulate as project collaborations end and cleanup never happens. Conditional Access policies get exceptions added to resolve a user complaint and those exceptions never get reviewed. Service principals get created for a vendor integration and sit with broad permissions long after the integration is decommissioned.

    Cloud configuration drift is not a sign of a bad IT team. It is the natural consequence of a dynamic environment managed under operational pressure without a systematic review cadence. The same organization that hardened their tenant in 2023 may have a materially different security posture in 2026 — not because anyone made a bad decision, but because dozens of small decisions accumulated without a review process to catch them.

    This is why cloud security review needs to be a recurring service with a defined cadence, not an annual project. A configuration that was compliant in January may not be compliant in June if a new guest was added with overpermissive roles, a legacy authentication protocol was re-enabled to support an old application, or a Conditional Access exclusion was added during a travel emergency and never removed. Detecting those changes — ideally within days, not months — is what turns a cloud security review from a point-in-time assessment into continuous protection.

    The Default Settings and Common Gaps Worth Reviewing

    What follows is not an exhaustive list of every Entra security setting. It is the areas where default configurations or common operational decisions most frequently create meaningful security gaps for regulated SMB clients — the ones that come up repeatedly in cloud security reviews and that map most directly to compliance control requirements.

    Multi-Factor Authentication coverage and Conditional Access policy gaps

    MFA is not a binary — it is not simply enabled or disabled across the tenant. The more operationally relevant question is which users are covered by which MFA requirements under which conditions, and whether there are gaps in that coverage that a threat actor could exploit. The specific areas to inspect: whether all privileged roles require phishing-resistant MFA (not just any second factor), whether Conditional Access policies have exclusions that cover more users than originally intended, and whether legacy authentication protocols — Basic Auth, older SMTP AUTH configurations — are blocked tenant-wide or selectively enabled for specific mailboxes or applications.

    Legacy authentication is the gap that shows up most consistently. Microsoft has deprecated Basic Authentication in Exchange Online, but legacy auth protocols can still be enabled for specific workloads, and some older client configurations or third-party integrations re-enable them without the IT team realizing the security implication. Legacy auth bypasses modern authentication entirely, which means MFA policies do not apply to those sessions. An attacker with a valid credential can authenticate via legacy auth and produce a fully valid session token regardless of what the Conditional Access policies say.

    Privileged role assignments and Privileged Identity Management

    Global Administrator is the highest-privilege role in an Entra tenant, and it is routinely over-assigned. Common findings: more than two to four Global Administrator accounts in a tenant of any size; service accounts or shared mailboxes assigned Global Admin because it was easier than scoping a more limited role; accounts assigned Global Admin for a project that concluded and the assignment was never removed; and no use of Privileged Identity Management for just-in-time elevation of privileged roles.

    Privileged Identity Management — available with Entra ID P2 or Microsoft 365 E3/E5 licensing — allows privileged role assignments to be time-limited and require explicit activation with justification and MFA. Without PIM, privileged role assignments are permanent and persistent. An account that is permanently assigned Global Admin is a high-value target in any BEC or credential compromise scenario. An account that can elevate to Global Admin for a four-hour window with MFA and an approval workflow is a substantially harder target for the same threat actor.

    Beyond Global Administrator, the review should include Exchange Administrator, SharePoint Administrator, and Security Administrator assignments — these are elevated enough to enable significant damage if compromised, but frequently assigned more broadly than Global Admin reviews catch.

    Guest account inventory and external collaboration settings

    Guest accounts in Entra ID represent external identities — vendors, consultants, contractors, partners — who have been granted some form of access to the tenant. The default settings for guest access are permissive: guests can enumerate other guests in the directory, see group memberships, and in some configurations access resources that were not intended to be shared externally. The default guest invitation settings allow any member of the tenant to invite external guests, which means the guest account inventory can grow substantially without IT visibility.

    For regulated clients, the guest account picture matters for compliance. CMMC, HIPAA, and PCI DSS all have access control requirements that apply to external parties with access to regulated data or systems. A guest account with Teams access to a SharePoint library that contains HIPAA-protected health information is an access control finding, not just a housekeeping issue. The review should cover: total guest account count and active vs. inactive status, which resources guests have access to, whether guests have access to any resources that contain regulated data, and whether the tenant-wide guest invitation settings restrict who can invite externals.

    Conditional Access policy completeness and exception hygiene

    Conditional Access policies are only as strong as their coverage. Common gaps that show up in reviews: policies that apply to most users but exclude break-glass accounts or service accounts in ways that create exploitable paths; policies that require compliant devices for some scenarios but have named location exclusions that effectively bypass device compliance for remote workers; sign-in risk policies configured but set to audit mode rather than enforcement; and policies that were effective when written but have not been reviewed against the current user and application inventory.

    Policy exceptions are the most common source of Conditional Access drift. An exception added for a traveling executive becomes permanent. An IP range added as a trusted location for an old office is never removed after a facility closure. A break-glass account excluded from all Conditional Access policies — which is appropriate — is also the highest-value target if compromised, and the monitoring and protection around that account needs to reflect its status.

    Application registrations and service principal permissions

    Application registrations and service principals represent non-human identities in the tenant — third-party applications, automation scripts, vendor integrations, and internal tools that have been granted API permissions to operate within the environment. The default behavior allows any user in the tenant to register applications, which means the app registration inventory can grow without centralized visibility or governance.

    The specific review areas: whether users are permitted to register applications without admin approval; which applications have been granted admin consent to tenant-wide API permissions (as opposed to user-delegated permissions); whether any service principals have permissions that are broader than their documented function; and whether any application registrations are associated with vendors or integrations that are no longer active. An application with tenant-wide Mail.Read or Files.ReadWrite.All permissions that was granted admin consent for a project two years ago and has never been used since is a persistent privilege that belongs in neither the environment nor the evidence package your client hands to an auditor.

    Security defaults and Microsoft Secure Score gaps

    Microsoft Secure Score is a useful starting baseline, but it has two limitations that MSPs need to account for. First, it reflects Microsoft’s general recommendations, not the specific requirements of your client’s compliance framework. A client can have a Secure Score of 70 and still have significant CMMC or HIPAA gaps because Secure Score is not a compliance assessment. Second, Secure Score recommendations are additive — they tell you what to turn on, but they do not always surface what should be turned off or tightened. A high score does not mean a clean tenant.

    For tenants that have Security Defaults enabled rather than Conditional Access policies — typically smaller tenants or those migrated without a configuration review — the review should assess whether Security Defaults are providing adequate coverage for the client’s specific risk profile, or whether the transition to a full Conditional Access policy set is warranted. Security Defaults provide a floor. For regulated clients with CMMC, HIPAA, or PCI DSS obligations, that floor is often below the required ceiling.

    Sign-in and audit log configuration and retention

    Entra ID generates sign-in logs and audit logs that are essential for incident response, compliance evidence, and detection of anomalous activity. The default retention for these logs in Entra ID is 30 days for sign-in logs and 30 days for audit logs in the free tier, and 90 days with a P1 or P2 license. For clients with HIPAA, CMMC, or PCI DSS obligations, 30 or 90 days is typically insufficient. HIPAA requires audit controls with documentation of system activity over a longer period. CMMC AU practices require audit log retention sufficient to reconstruct security-relevant events.

    The review should confirm whether logs are being forwarded to a SIEM or long-term storage solution outside of Entra, what the effective retention period is for sign-in and audit data, and whether the logging configuration captures the events required by the client’s applicable compliance framework. A client who cannot produce 12 months of sign-in history for a specific account during an audit or incident investigation has a compliance gap that no amount of Conditional Access policy cleanup will address.

    What to Review Before Your Next QBR

    The QBR is the natural moment to surface cloud identity findings to a client — both because it is a structured conversation about business outcomes and because it creates a recurring rhythm that prevents the review from slipping into annual-scramble territory. A structured Entra review ahead of each QBR gives you specific, client-named findings to discuss rather than generic security posture observations.

    The pre-QBR Entra review should cover these areas at minimum, organized in the order that maps most directly to compliance requirements and business risk:

    MFA coverage audit. Pull the current list of users without registered MFA methods. Filter for users with access to regulated data or systems. Any user in that filtered list who lacks MFA registration is an active, specific risk to surface in the QBR — with a name, a role, and the compliance control it implicates.

    Privileged role review. Pull the current list of all Global Administrator, Exchange Administrator, SharePoint Administrator, and Security Administrator role assignments. Compare to the prior quarter’s list. Any new assignments, any assignments to accounts that are not primary IT staff, or any count above four Global Admins should be flagged for discussion.

    Guest account activity review. Pull all guest accounts and filter for those with no sign-in activity in the past 90 days. Stale guest accounts are both a security risk and a compliance evidence gap. Present the count to the client and recommend a review-and-remove cycle before the QBR meeting.

    Conditional Access exception review. Review all active Conditional Access policy exclusions. Any exclusion that covers more than two or three named accounts, or any exclusion added more than 90 days ago that has not been re-evaluated, is a finding worth discussing.

    Legacy authentication status. Confirm whether legacy authentication is blocked via Conditional Access across all protocols for all users. If any legacy auth-capable flows are active, identify the application or user that requires it and whether a modern alternative is available.

    App permissions review. Pull admin-consented application permissions and flag any applications with broad graph API permissions (Mail.Read, Files.ReadWrite.All, Directory.ReadWrite.All, or similar) that are not actively documented and business-justified.

    Log retention verification. Confirm that sign-in and audit logs are being forwarded to a retention solution outside of the default 30/90-day Entra window, and that the retention period meets the requirement for the client’s applicable compliance framework.

    The QBR presentation of these findings should frame each item in business terms: which risk it represents, which compliance obligation it is relevant to, and what remediation looks like in practical terms. “Your Exchange Administrator role is assigned to six accounts, and three of them have not been active in the past six months” is a more useful client communication than a generic statement about privileged access hygiene.

    Connecting Identity Findings to Compliance Evidence

    An Entra ID security review is not just a technical exercise — it is compliance evidence generation. Every finding you document, every remediation you complete, and every configuration you validate against a security baseline produces evidence that maps to specific framework controls across CMMC, HIPAA, PCI DSS, SOC 2, and NIST CSF.

    For CMMC-obligated clients, the identity review covers Access Control (AC) practices around least privilege, account management, and remote access; Identification and Authentication (IA) practices around MFA, password management, and identifier management; Audit and Accountability (AU) practices around log retention and access audit trails; and Configuration Management (CM) practices around configuration baselines and change tracking. A structured identity review that produces documented findings against these domains is contributing directly to the evidence package the client needs for their SPRS submission and eventual C3PAO assessment.

    For HIPAA-obligated clients, the identity review maps to the Access Control (§164.312(a)(1)) and Audit Controls (§164.312(b)) implementation specifications under the Technical Safeguards. The guest account review and privileged role review are direct contributions to the Access Control requirement for unique user identification and access to electronic protected health information.

    For SOC 2 clients in the certification process, the Logical and Physical Access Controls criterion is one of the most evidence-intensive sections of the audit. Quarterly Entra reviews with documented findings, remediation records, and user access certifications are exactly the type of evidence a SOC 2 auditor reviews under CC6.1 through CC6.7.

    The practical implication: the Entra review your team does before each QBR should produce a structured, dated document — not just notes in a ticket — that can be incorporated into the quarterly compliance evidence package. A dated document showing that privileged role assignments were reviewed, guest accounts were audited, and Conditional Access policies were validated is audit-ready evidence. Notes in a PSA ticket are not.

    Operationalizing the Review

    A structured Entra ID security review needs three things to be a repeatable managed service rather than an ad hoc project: a defined checklist that runs the same way every time, tooling that surfaces configuration changes and drift without requiring manual queries, and a documentation workflow that produces dated evidence rather than undated notes.

    The checklist is the starting point. A checklist that your team works through the same way for every client, every quarter, produces consistent output — consistent enough that a compliance auditor reviewing two years of quarterly evidence packages can see a continuous, structured practice rather than a series of unrelated snapshots.

    Tooling that detects configuration drift between reviews closes the gap between quarterly review cycles. A Conditional Access policy that gets a new exception in week two of the quarter should not wait until week thirteen to surface. Cloud security configuration monitoring — daily or continuous, depending on the client’s risk profile and service tier — gives your team visibility into changes as they happen rather than changes that have been in place for 90 days by the time you review them.

    → The SentinelBaseline Platform page covers cloud and identity security review cadence across service tiers — from monthly review at Baseline to daily cloud drift detection at higher tiers — and how those outputs integrate with compliance framework mapping.

    The documentation workflow ensures that what the review finds becomes evidence. The output of each review should be a dated findings document organized by review area, with the current status, any changes from the prior review, and remediation actions taken or recommended. That document — stored in your documentation system and shared with the client — is what turns a recurring review into a continuous compliance evidence record.

    → Southern Sentinel’s channel-exclusive model is built specifically for MSPs serving regulated SMBs — the platform provides the cloud and identity security review infrastructure; your team provides the client relationship and remediation delivery. The billable hours from findings remediation stay with your practice.

    If you want to see how the platform’s cloud identity review, Entra configuration monitoring, and compliance-mapped reporting work in practice — and how to structure this as a recurring, billable service for your M365 client base — book a 30-minute demo.

    → Book a Demo

    Frequently Asked Questions

    How often should an Entra ID security review be conducted?

    For regulated clients — CMMC, HIPAA, PCI DSS — a structured review should happen at minimum quarterly, aligned to the QBR cycle. For clients with higher risk profiles or more dynamic environments, monthly review is more appropriate. Between structured reviews, continuous or daily configuration drift detection fills the gap — surfacing changes to Conditional Access policies, role assignments, and guest account status as they happen rather than waiting for the scheduled review date. The review cadence should match the client’s compliance requirements and how frequently their environment changes, not a convenient scheduling interval for your team.

    What licenses are required to review and remediate these settings?

    Most of the review areas in this article are accessible with any Entra ID tier, including the free tier included with Microsoft 365 Business Basic. Conditional Access policies and Privileged Identity Management require Entra ID P1 and P2 respectively — P1 is included in Microsoft 365 Business Premium, and P2 is included in Microsoft 365 E5 or available as an add-on. Sign-in log retention beyond 30 days requires P1 or P2. For clients on Business Basic or Business Standard without P1, the absence of Conditional Access is itself a significant finding — the conversation about licensing is part of the remediation discussion, not a separate conversation.

    How do I explain Entra security review findings to a non-technical client?

    Frame findings in terms of the risk they represent and the specific compliance obligation they affect, not in technical configuration language. “Six accounts have permanent Global Administrator access, including two that have not signed in for four months — if either of those accounts is compromised, an attacker has full administrative access to your entire Microsoft 365 environment with no additional barriers” is a communication a non-technical client understands and can act on. The technical remediation detail — removing stale assignments, implementing PIM for active admins — goes in the service notes, not the client conversation. The business risk goes in the QBR.

    What is cloud drift and why does it matter between reviews?

    Cloud configuration drift is the gradual divergence of a cloud environment from its intended security baseline — caused by the accumulation of small operational decisions, exceptions, and workarounds that each seem reasonable in isolation but degrade the overall security posture over time. It matters between reviews because a quarterly review cadence means 90 days of potential drift before detection. A Conditional Access exception added in week one is active for the remaining 12 weeks of the quarter before you review it. A new guest account added with overpermissive access operates without scrutiny for the same period. Continuous drift detection — alerting when configurations change outside of an approved change process — reduces that exposure window from weeks to hours.

    Does an Entra ID review require special permissions in the client tenant?

    Reading most of the configuration areas covered in this article requires Global Reader, Security Reader, or a combination of role-specific read permissions. You do not need Global Administrator access to conduct the review — read-only roles are sufficient for assessment purposes. For any remediation actions — removing role assignments, modifying Conditional Access policies, revoking application permissions — more elevated permissions are required, and those actions should follow your standard change management process with client awareness and approval before execution. The review and the remediation are separate activities with different permission requirements.

    How do these findings relate to Microsoft Secure Score?

    Microsoft Secure Score captures many of the same configuration areas but has important limitations as a compliance tool. It reflects Microsoft’s general recommendations, not the specific requirements of CMMC, HIPAA, or PCI DSS. It does not surface guest account inventory issues, stale role assignments, or Conditional Access exception accumulation in the same granular way a structured review does. It also cannot tell you whether log retention meets a specific compliance framework’s requirements. Use Secure Score as a quick directional indicator — a tenant scoring below 50 almost certainly has significant gaps — but do not use it as a substitute for a structured review. Compliance auditors and C3PAO assessors will ask about specific controls, not about your Secure Score.

  • How to Help Your DIB Clients Prepare for a CMMC Level 2 Assessment

    CMMC 2.0 Phase 1 enforcement is live as of November 10, 2025. Under Phase 2, beginning November 10, 2026, most defense contractors handling Controlled Unclassified Information will require third-party certification by a Certified Third-Party Assessment Organization — a C3PAO. The gap between “we know we need to be ready” and “we actually are ready” for most DIB clients is significant, and the preparation timeline is measured in months, not weeks.

    As the MSP managing these clients’ IT environments, you are in the best position to drive that preparation — and to structure it as a billable, ongoing engagement rather than a reactive scramble. This article is a step-by-step guide for MSPs: how to scope the work, map the gaps, prioritize remediation, generate evidence, and communicate progress to the client in a way that is credible and specific rather than reassuring but vague.

    This is not a repeat of the conceptual overview. It is the tactical sequence: what you do, in what order, and why each step matters for the assessment outcome.

    Step 1 — Define the Scope Before Anything Else

    The most expensive mistake in CMMC preparation is starting the technical work before the scope is defined. Scope determines which systems, networks, personnel, and data flows fall inside the CMMC assessment boundary — and everything outside that boundary does not need to be assessed. Preparing the wrong systems wastes time, inflates cost, and produces an evidence package that does not align with what the C3PAO will actually evaluate.

    Scoping a CMMC Level 2 assessment starts with identifying where CUI lives. The client needs to know which systems create, process, store, or transmit Controlled Unclassified Information — and that means getting specific: which servers, which workstations, which cloud services, which personnel roles. A client who answers “everywhere” has not done the scoping work. CUI scope should be defined, documented, and connected to the specific contracts that require it.

    The scope document needs to describe the assessment boundary clearly enough that the C3PAO assessor can determine what to test without asking you to explain it during the assessment. That document — sometimes called an Asset Inventory and Network Diagram, sometimes incorporated into the System Security Plan — is the first deliverable of the preparation engagement. Everything else builds on it.

    Key scoping questions to work through with the client:

    • Which contracts require CMMC Level 2 certification? Are there subcontract flowdown clauses?
    • Which systems handle CUI? Can any of those systems be isolated from systems that do not?
    • Which personnel roles have access to CUI? Are those roles clearly defined and documented?
    • Which cloud services are in scope? What is the cloud service provider’s FedRAMP authorization status?
    • Does any CUI leave the primary environment — through remote access, portable media, or third-party vendor access?

    A tighter scope is almost always better than a broader one — as long as it accurately reflects where CUI exists. The goal is not to hide anything from the assessor. It is to ensure you are not doing remediation work on systems that have nothing to do with CUI handling.

    Step 2 — Run the Gap Assessment Against All 110 Practices

    Once scope is defined, the gap assessment maps the client’s current control state against all 110 security requirements in NIST SP 800-171 Revision 2, which is the technical baseline for CMMC Level 2. This is not a questionnaire that the client fills out about themselves. It is a technical assessment that produces evidence-backed answers to whether each practice is implemented, partially implemented, or not implemented.

    The 110 practices span 14 domains: Access Control, Awareness and Training, Audit and Accountability, Configuration Management, Identification and Authentication, Incident Response, Maintenance, Media Protection, Personnel Security, Physical Protection, Risk Assessment, Security Assessment, System and Communications Protection, and System and Information Integrity. Each domain has a different weight in terms of the risk profile a gap creates, and assessors will not spend equal time on all domains.

    For each practice, the gap assessment should produce three things: the current implementation status, the specific evidence that exists to support that status, and — if the practice is not fully implemented — the gap that needs to be closed. “Partially implemented” is not a safe resting state for most Level 2 practices. Assessors look for evidence that a control is operating as intended, not just that a policy exists that says it should.

    The output of the gap assessment is the foundation of both the System Security Plan and the Plan of Action and Milestones. You cannot write either document credibly without the gap assessment data. MSPs who skip the technical gap assessment and go straight to documentation are producing paper that will not survive an assessor’s scrutiny.

    Platform-level mapping — where vulnerability scan findings and configuration data are automatically aligned to specific CMMC practices at the control level — dramatically reduces the labor required to run a credible gap assessment at scale. Manual mapping across 110 practices for each client is feasible for one engagement. It is not a repeatable business model. Practice-level alignment built into your tooling is what makes the gap assessment a structured, consistent service rather than a bespoke project each time.

    → See how Sentinel’s CMMC alignment works at the practice level — specific control mapping, not just framework presence — and how that changes what the gap assessment output looks like for an assessor.

    Step 3 — Build the System Security Plan and POA&M

    The System Security Plan is the central document in a CMMC Level 2 assessment. It describes the client’s information system, the security requirements applicable to it, and how each requirement is met. The C3PAO assessor will review the SSP before the formal assessment begins — it sets their expectations and tells them where to look for evidence. An incomplete or inconsistent SSP signals that the client is not prepared, before the technical testing even starts.

    An SSP for CMMC Level 2 needs to include a system description and boundary diagram, a description of how each of the 110 practices is implemented (or planned to be implemented), identification of any inherited controls from cloud service providers or other external entities, and a reference to the Plan of Action and Milestones for any practices not yet fully implemented.

    The Plan of Action and Milestones documents every gap identified in the gap assessment — what the current state is, what the target state is, who is responsible for closing the gap, and by what date. The POA&M is not a weakness; it is evidence of a mature, managed approach to risk. An assessor reviewing a POA&M with specific dates, responsible parties, and milestone tracking is seeing a client who understands their gaps and is actively addressing them. An assessor who finds undocumented gaps during the assessment that were not in the POA&M is seeing a client who either did not know about them or was not transparent — either of which creates a more difficult assessment outcome.

    Practically: the SSP and POA&M should be living documents, updated as remediation progresses. Do not write them once and file them. The CMMC certification process requires continuous compliance attestation — the documents need to reflect the current state of the environment at the time of assessment, not the state six months earlier when you first wrote them.

    Step 4 — Prioritize Remediation by Assessment Risk, Not CVSS Score

    Not all gaps carry the same weight in a CMMC Level 2 assessment. Prioritizing remediation by CVSS severity score — the default output of most vulnerability scanners — will send your clients in the wrong direction. A medium-CVSS misconfiguration in Access Control that allows unauthorized lateral movement is a more serious assessment risk than a high-CVSS vulnerability in a system outside the CUI boundary. The assessment risk of a gap depends on which practice it implicates, how central that practice is to the domains assessors scrutinize most closely, and whether a similar gap has been exploited in recent defense contractor incidents.

    The domains that consistently receive the closest scrutiny in Level 2 assessments are Access Control, Identification and Authentication, Audit and Accountability, and Configuration Management. These four domains account for a disproportionate share of both common gaps and assessment findings. If your client has unresolved gaps in any of these domains, those should be at the front of the remediation queue regardless of their CVSS severity rating.

    Within those high-priority domains, the specific practices that assessors focus on most heavily include multi-factor authentication requirements (IA domain), least-privilege access controls (AC domain), audit logging with sufficient detail to reconstruct events (AU domain), and baseline configuration management with documented deviations (CM domain). A client who has robust implementations of these practices — with evidence — is in a substantially stronger position than one who has patched every high-CVSS vulnerability but left MFA and audit logging gaps in place.

    The remediation priority framework your team uses should sequence work in three tiers: practices that are not implemented at all in high-scrutiny domains come first; practices that are partially implemented with evidence gaps in high-scrutiny domains come second; and practices with lower assessor scrutiny or outside the CUI boundary come third. This sequencing is not about cutting corners on lower-priority items — it is about ensuring the most assessor-visible gaps are closed before the assessment date.

    Step 5 — Build and Maintain the Evidence Package

    CMMC Level 2 assessors are not evaluating what your client says they do. They are evaluating what the evidence shows they do. For each practice, the evidence needs to demonstrate that the control is implemented, that it is configured correctly, and that it is operating consistently over time — not just at the moment of the assessment.

    For most Level 2 practices, the evidence consists of two categories: technical evidence and procedural evidence. Technical evidence includes configuration records, scan results, access control logs, audit logs, patch management history, and system-generated artifacts that demonstrate a control is operating as configured. Procedural evidence includes policies, procedures, training records, and workflow documentation that demonstrate the organization has defined how a control is implemented and that personnel follow those definitions.

    Both categories are required for most practices. A policy that says MFA is required for remote access does not satisfy the IA.L2-3.5.3 practice if there are no technical artifacts showing that MFA is actually enforced. Conversely, a technical configuration showing MFA is enforced does not satisfy the practice if the remote access policy has not been updated to reflect the requirement. Assessors look for both, and missing either creates a finding.

    The practical implication for MSPs is that evidence collection needs to be ongoing, not pre-assessment. Scan reports all dated within the month before the assessment, log exports pulled specifically because the assessor is coming, and policies written the week before the review — these patterns are visible to assessors and undermine the credibility of the evidence even when the controls themselves are in place. The evidence needs to show a continuous, consistent practice, which means your monitoring cadence and documentation workflow need to run year-round.

    Step 6 — Prepare and Submit the SPRS Score

    The Supplier Performance Risk System is the DoD’s portal for tracking contractor cybersecurity compliance status. Under Phase 1 of CMMC, Level 2 contractors who are permitted to self-assess must calculate a score based on their NIST 800-171 compliance and submit it to SPRS, along with an annual executive affirmation signed by a senior company official.

    The SPRS score is calculated by starting at 110 points and subtracting weighted penalties for each unimplemented or partially implemented practice. A fully compliant organization scores 110. An organization with significant gaps may score zero, negative, or — if gaps are severe enough — deeply negative. Whatever the score is, it must be submitted accurately. Contracting officers check SPRS scores before awarding contracts. A missing submission disqualifies a contractor from bidding on covered solicitations. A score submitted that does not reflect actual implementation is a potential False Claims Act violation.

    For clients who will require C3PAO certification under Phase 2 rather than self-assessment, the SPRS submission remains relevant — it reflects the current posture while certification is being pursued. Help your client calculate an accurate score based on the gap assessment results and ensure it is submitted and kept current. A stale or missing SPRS entry creates risk in the period between now and the formal certification.

    What MSPs Should Have Ready Before the Assessor Conversation

    When your client schedules their C3PAO assessment, the preparation enters a different phase. The assessor will request documentation before the assessment begins — typically two to four weeks in advance — and will use that documentation to set their testing plan. What you have ready at that moment determines how the assessment unfolds.

    A current, complete System Security Plan. This is the document the assessor reads first. It should describe every in-scope system, every applicable practice, and how each is implemented. It should be accurate as of the assessment date — not the date you last updated it. If there have been infrastructure changes since the SSP was written, update it before submission.

    A clean, current POA&M. Every open gap should be in the POA&M with a realistic closure date and a responsible party. Gaps that are in the POA&M with active milestones are assessed differently than gaps the assessor discovers independently. The POA&M does not hide weaknesses — it demonstrates managed awareness of them, which is a different assessment outcome than undisclosed gaps.

    A documented asset inventory and network diagram. The assessor needs to understand the boundary before testing can begin. The network diagram should show all in-scope systems, their connections to each other and to external networks, and any boundary protection controls. The asset inventory should match the diagram. Inconsistencies between the two raise questions that take time to resolve and create distrust of the documentation generally.

    Organized evidence files mapped to practices. Do not hand the assessor a pile of scan reports and log exports and ask them to find the evidence for each practice. Organize the evidence package so that for any given practice, you can immediately produce the relevant technical and procedural evidence. A folder structure organized by domain and practice number, with a coverage index that shows which evidence satisfies which practice, saves time during the assessment and demonstrates preparation maturity.

    A current SPRS submission that matches the SSP. If the SPRS score was calculated based on a different gap assessment than the SSP reflects, the discrepancy will surface. Ensure the SPRS submission, the SSP, and the POA&M are all internally consistent before the assessor conversation begins.

    A designated technical point of contact for the assessment. The assessor will have questions — specific, technical questions about configurations, access control implementations, and audit log settings. The person answering those questions needs to know the environment well enough to answer them accurately and in detail. Brief that person on the SSP, the gap assessment findings, and the remediation history before the assessment begins. An assessor who encounters uncertainty or inconsistency in technical answers spends more time testing, not less.

    Pre-Assessment Readiness Checklist

    Use this as a structured reference in the weeks before the assessment date. Every item should have a clear owner and a confirmed completion date before the assessor conversation is scheduled.

    Scoping and documentation

    • CUI inventory complete — all systems, personnel roles, and data flows documented
    • Assessment boundary defined and approved by client leadership
    • Network diagram current and consistent with asset inventory
    • System Security Plan updated to reflect current environment and controls
    • POA&M current with accurate status, milestone dates, and responsible parties for all open items
    • SPRS score calculated, submitted, and consistent with SSP
    • Annual executive affirmation completed and on file

    Evidence collection

    • Vulnerability scan history available for in-scope systems (minimum 6 months preferred)
    • Patch management records demonstrating remediation cadence
    • Access control audit logs with sufficient retention and detail
    • MFA implementation evidence for all in-scope remote and privileged access
    • Configuration baseline documentation with deviation records
    • Incident response log and test documentation
    • Security awareness training completion records for all personnel with CUI access
    • Media protection records (sanitization logs, transfer authorizations)
    • Physical access control logs for systems in scope
    • Evidence organized by domain and practice with coverage index

    Gap and remediation status

    • All high-scrutiny domain gaps (AC, IA, AU, CM) either closed or documented in POA&M with milestones
    • No undisclosed gaps — everything discovered in gap assessment is in the SSP or POA&M
    • Remediation tickets closed in PSA with documented evidence of completion
    • Any conditional POA&M items have realistic 180-day closure timelines (required for conditional certification)

    Assessment preparation

    • Technical point of contact briefed on SSP, gap findings, and remediation history
    • Evidence package organized and accessible — not buried in raw scan exports
    • Pre-assessment readiness review completed 90 days before assessment date
    • Documentation pre-submission package prepared for C3PAO two to four weeks before assessment

    Client Communication Throughout the Process

    One of the places MSPs lose credibility in CMMC preparation engagements is in client communication. The technical work is solid; the client updates are vague. “We’re making good progress” and “things are on track” are not meaningful answers for a client whose contract eligibility depends on passing a C3PAO assessment by a specific date. Specific, structured progress communication is part of the service.

    A monthly status update should include: the current SPRS score, the count of practices by status (implemented, partially implemented, not implemented), the practices closed during the month, the practices targeted for the next month, and any blockers — client decisions, third-party dependencies, or resource constraints — that are affecting the timeline. That is a communication that a client can share with their legal counsel, their prime contractor, or their own leadership. It demonstrates managed progress, not reassuring vagueness.

    The other communication moment that requires care is when gaps are discovered that the client did not expect. The instinct is to soften the message — to frame a significant gap as “something we are working through” rather than as the concrete assessment risk it represents. The better approach is to be specific about what the gap is, which CMMC practice it implicates, what an assessor would likely do with it if it were unresolved at assessment time, and what remediation looks like. Clients who receive specific information make better decisions about prioritization and timing than clients who receive reassurance.

    If you want to see how the Sentinel platform’s practice-level CMMC mapping, continuous scanning, and evidence generation support the preparation workflow described here — and how to structure this as a repeatable engagement for your DIB client base — book a 30-minute demo.

    → Book a Demo

    Frequently Asked Questions

    How far in advance of the assessment should preparation begin?

    For a client starting from a significant gap — which describes most DIB contractors — six to twelve months is the realistic preparation window for Level 2 C3PAO readiness. That time covers the scoping work, the technical gap assessment, SSP and POA&M development, remediation implementation, evidence collection, and a pre-assessment readiness review. Clients who begin preparation three months before the Phase 2 mandatory date in November 2026 are not on a comfortable timeline. The readiness review should happen approximately 90 days before the scheduled assessment, which means the preparation work needs to be substantially complete at that point.

    What happens if gaps remain at assessment time?

    Gaps at assessment time do not automatically result in a failed certification. The assessor determines whether the gap can be addressed through a conditional certification with a Plan of Action and Milestones. If the gap is documented in the POA&M with a realistic closure milestone — generally within 180 days of certification — the assessor may allow a conditional certification. However, the POA&M item must be closed within that window or the certification expires. Gaps that are not in the POA&M and are discovered by the assessor are treated differently — they reflect an incomplete assessment process rather than managed risk, and the assessment outcome is more difficult to predict.

    Does the MSP need to be present during the C3PAO assessment?

    The MSP is typically not a formal party to the assessment — the assessment is between the C3PAO and the contractor. However, as the party managing the client’s technical environment, your team will almost certainly be involved in answering technical questions, producing evidence, and demonstrating configurations during the assessment. Brief your technical contact on the SSP and evidence package before the assessment begins, and ensure your team is available to support the client’s designated point of contact when the assessor requests system access or technical demonstrations.

    How does cloud infrastructure affect CMMC scoping and assessment?

    Cloud services in the assessment boundary introduce additional scoping questions that need to be resolved before the SSP is written. Cloud Service Providers used to store, process, or transmit CUI need to be either FedRAMP Authorized at the Moderate baseline or meet equivalent security requirements. If the client is using a cloud service that does not meet these requirements for CUI handling, that is a scoping and remediation issue, not just a documentation issue. The assessor will verify cloud service authorization status as part of the assessment. Resolving cloud scope questions early — ideally in the initial scoping phase — prevents late-stage surprises that affect the assessment timeline.

    What is the difference between a self-assessment and a C3PAO assessment for Level 2?

    Under Phase 1 (in effect since November 2025), many Level 2 contracts allow self-assessment — the contractor evaluates themselves against the 110 practices, calculates an SPRS score, and has a senior official attest to the accuracy of that assessment. The DoD retains discretion to require C3PAO certification for specific high-priority programs even during Phase 1. Under Phase 2 (beginning November 10, 2026), most contracts involving CUI require third-party certification by a C3PAO rather than self-assessment. The evidence standard, documentation requirements, and consequences of inaccurate attestation are the same in both cases — the difference is whether a third-party organization is independently verifying the assessment. For a contractor who has never had their environment externally assessed, the C3PAO will almost always surface gaps that the self-assessment did not.

    Can my client start the assessment process and remediate during the observation period?

    Not in the way that sometimes gets suggested. The C3PAO assessment evaluates the environment as it exists at the time of the assessment, not as it is planned to exist after remediation. Remediation items that are documented in the POA&M before the assessment can be handled through conditional certification, but remediation that begins after the assessor arrives does not affect the assessment outcome. The preparation work — scoping, gap assessment, remediation, evidence generation — needs to be substantially complete before the C3PAO engagement begins. This is why the preparation timeline matters: the assessment is not the beginning of a compliance journey, it is the validation of one.

  • Compliance Documentation as a Managed Service: How MSPs Can Turn Annual Work Into Recurring Revenue

    Most MSPs treat compliance documentation the same way their clients treat taxes: something you rush through once a year, hand off to someone who scrambles to assemble it, and then try to forget about until next time. The result is a frantic few weeks before an audit, a manually assembled evidence package that nobody is confident in, and an invoice that the client resents because the work felt reactive and disorganized rather than valuable.

    There is a better model — and it is more profitable, more defensible, and significantly easier to deliver than the annual scramble approach. The model is treating compliance documentation as a managed service: a defined, recurring engagement with predictable deliverables, a structured cadence, and a billing rate that reflects ongoing value rather than emergency labor.

    This article is about how to build that model inside your MSP — what it includes, how to price and package it, and why clients who understand what they are getting will pay for it without negotiation.

    Why the Annual Scramble Costs You More Than It Earns

    The once-a-year compliance documentation engagement has several problems that compound each other.

    The first problem is labor intensity concentrated at the worst possible moment. When an audit or assessment is three weeks out, your team is pulling scan results, cross-referencing them against framework controls, writing summaries, chasing missing documentation from the client, and assembling a package under pressure. That work is expensive in human time and often billed at a rate that does not actually recover the cost — because the client did not budget for it, and charging what it actually cost would feel punitive for work that arguably should have been happening all year.

    The second problem is evidence quality. Compliance documentation assembled in a three-week sprint before an assessment is almost never as strong as documentation built and maintained throughout the year. Assessors and auditors are not just looking at the document — they are looking at the date stamps, the continuity of the record, and whether the evidence reflects an ongoing practice or a retroactive reconstruction. A stack of scan reports all dated within the same month looks like what it is.

    The third problem is retention risk. An MSP whose primary compliance value-add is “we scramble before your audit” is easy to replace. Another provider can do the same scramble at a lower price. An MSP whose compliance documentation service is woven into the monthly delivery — where pulling the plug on your agreement means losing the ongoing evidence record, the framework-mapped findings history, and the institutional knowledge of the client’s control posture — has a fundamentally different retention dynamic.

    What Deliverables Clients Actually Value

    Before building a managed compliance documentation service, it helps to be clear on what clients are actually trying to accomplish with the documentation you produce. Understanding the end use changes what you deliver and how you frame it.

    The auditor or assessor package. When a client faces a CMMC C3PAO assessment, a HIPAA audit, a PCI QSA review, or a SOC 2 audit, what the auditor wants is evidence that specific controls have been implemented and are operating continuously. Not a policy document. Not a self-attestation. Evidence: scan results, access control logs, configuration records, patch history, incident response documentation, and framework-mapped findings that connect each piece of evidence to the specific control it satisfies. Building that package reactively takes weeks. Maintaining it continuously means it is always ready.

    The insurance renewal submission. Cyber insurers have materially tightened their underwriting questionnaires. They want to see vulnerability scan history, patch cadence, MFA implementation, incident response documentation, and evidence of ongoing security monitoring. A client who can produce a year’s worth of continuous scan reports, a framework-mapped findings summary, and a documented remediation history is a substantially better underwriting risk than a client who hands over a single recent scan and a self-completed questionnaire. The documentation directly affects coverage terms and premium.

    The client’s internal stakeholders. The CISO equivalent at a mid-market company, the practice manager at a healthcare practice, the CFO who has to sign off on the security budget — these people need to be able to explain what the security investment is delivering. A quarterly evidence package that shows what was scanned, what was found, what was remediated, and how that maps against the relevant compliance framework gives those stakeholders something they can read, share, and use to justify the ongoing investment. Raw scan output does not.

    The contract or procurement requirement. Enterprise customers and government primes increasingly require vendor security documentation as a condition of doing business — not just at onboarding but on an ongoing basis. A client who can produce current, structured compliance documentation on demand closes deals and maintains contracts that their competitors lose for inability to produce the paperwork.

    The common thread across all of these is that raw scan output has no direct value to any of these audiences. What has value is findings mapped to specific framework controls, organized into a package that an auditor, insurer, executive, or procurement officer can navigate without a security background. That mapping and organization is what you are selling — and what justifies a recurring billing rate.

    A Recurring Compliance Documentation Service Model

    The structure below is a practical starting point for packaging compliance documentation as a managed service. It follows a monthly, quarterly, and annual cadence that keeps the work distributed across the year, the evidence continuously maintained, and the client relationship anchored to ongoing deliverables rather than annual panic.

    Monthly: The Security Findings Review

    The monthly deliverable is a structured findings report — not raw scan output, but a curated summary of what the scan found, how findings compare to the prior month, which items were remediated, which are newly discovered, and how the overall posture is trending. Findings should be mapped to the relevant compliance framework controls so the client understands not just what is wrong but why it matters in the context of their specific obligations.

    The monthly report also includes open remediation items with status updates — which tickets were created in the PSA, which were closed, and which are still in progress with expected resolution dates. This creates a documented remediation trail that serves as evidence of ongoing risk management rather than a static point-in-time snapshot.

    Time investment, once tooling is in place: typically one to two hours per client per month for review, interpretation, and report generation. With platform tooling that generates framework-mapped output automatically, the human time is in interpretation and client-facing write-up — not in assembling the data.

    Quarterly: The Evidence Package

    The quarterly deliverable is the assembled evidence package — the document set that an auditor would actually review. It pulls together the three months of findings reports, the remediation history, the current control coverage status against the relevant framework, and any supporting documentation the client needs to maintain.

    For a HIPAA-obligated client, the quarterly evidence package includes a Security Risk Assessment update, a summary of access control reviews conducted during the quarter, incident log documentation, and a mapping of current vulnerabilities to the HIPAA Security Rule safeguards they implicate. For a CMMC-obligated client, it maps to the specific practices relevant to their level and includes the current System Security Plan status and any POA&M updates.

    The quarterly package is the deliverable that most directly replaces the annual scramble. A client who receives this four times a year does not have a compliance documentation problem when their assessment arrives — they have a current package that needs a cover letter and a date stamp, not three weeks of reconstruction work. One healthcare-focused MSP partner who structured their engagement this way replaced a process that had previously taken two to three days per client per quarter — and that time was being consumed by their own team, not billed. The structured quarterly package eliminated that waste and created a billable deliverable where there had previously been none.

    Annual: Assessment Readiness Preparation

    The annual deliverable is the full assessment readiness review — a comprehensive walkthrough of the client’s compliance posture against their primary framework, identifying any gaps in the evidence package, control deficiencies that need remediation before the assessment, and a preparation checklist for the audit itself.

    For clients who face formal third-party assessments — CMMC C3PAO review, SOC 2 audit, PCI QSA — this annual review is scheduled three to four months before the assessment date, leaving time to address any findings before the assessor arrives. For clients with softer compliance obligations — insurance renewals, customer security questionnaires — it aligns with the renewal cycle.

    The annual review is also the natural renewal conversation for the managed compliance service itself. A client who has received twelve monthly reports and four quarterly evidence packages over the past year has concrete evidence of the service’s value — in the form of their own security history. Renewing the service is not a sales conversation at that point. It is a continuation of something that is visibly working.

    → See how the SentinelBaseline Platform’s compliance mapping and audit artifact generation supports this delivery model — including daily artifact generation at the Supreme tier and framework mapping across all seven supported frameworks.

    Packaging the Service for the Client Conversation

    The way you package and describe this service determines whether clients perceive it as a commodity or a premium engagement. Three framing principles make a meaningful difference.

    Lead with the output, not the process. Clients do not buy vulnerability scans. They buy the ability to pass their audit, satisfy their insurer, and answer their prime contractor’s security questionnaire. Package the service around the deliverable — “you receive a monthly findings review, a quarterly evidence package, and an annual readiness assessment” — rather than around the tooling that produces it. The platform is the factory. The deliverables are the product.

    Name the framework explicitly. A client under HIPAA pressure is not buying “compliance documentation services.” They are buying a HIPAA-aligned security program with quarterly audit-ready evidence packages. The framework specificity signals that the service is purpose-built for their situation, not a generic offering they could get from any MSP. Seven frameworks — CMMC 2.0, NIST CSF 2.0, NIST 800-171, CIS Controls v8, PCI DSS, HIPAA, and SOC 2 — means you can position distinctly for each client segment rather than offering a one-size-fits-all product.

    Separate documentation from remediation billing. The compliance documentation service — scanning, mapping, reporting, evidence packaging — is a fixed monthly fee. Remediation work — the actual patching, reconfiguration, and control implementation that findings generate — is billed separately as professional services. This separation is important for two reasons. First, it protects your documentation service margin from being eroded by variable remediation labor. Second, it creates a natural and legitimate upsell: the scan finds it, the report documents it, and your team bills to fix it. The remediation work stays with your practice, not a third-party vendor.

    What Differentiates Documentation as a Service From a Scan Report

    The distinction between raw scan output and audit-ready documentation is the entire value proposition of the managed compliance service model. It is worth being explicit about what that distinction means in practice, because it determines how you train your team, what your tooling needs to produce, and how you explain the service to clients.

    Raw scan output tells you what vulnerabilities exist in the environment. It is a list of findings with severity ratings, CVE numbers, and remediation suggestions. This is useful to a security practitioner who knows what to do with it. It is not useful to a HIPAA auditor, an insurance underwriter, or a CFO trying to understand their security posture.

    Audit-ready documentation takes those findings and connects them to specific framework controls, translates them into business language, contextualizes them within the client’s overall posture and remediation history, and assembles them into a structured package that a non-technical stakeholder can review. The underlying data is the same. The work product is entirely different — and so is the price that work product commands.

    The key operational requirement for delivering this at scale is platform tooling that does the framework mapping automatically. Manual mapping of scan findings to HIPAA safeguards or CMMC practices is feasible for one or two clients. It is not feasible for ten, and it is impossible to standardize across a team. Platform-level framework mapping — where findings are automatically tagged to the relevant controls in whichever frameworks the client is subject to — is what makes the managed compliance documentation service scalable without proportionally scaling your headcount.

    → See how Sentinel’s compliance depth compares to typical platform approaches — specifically the distinction between framework presence and practice-level alignment that determines whether your documentation actually holds up under assessor scrutiny.

    Pricing the Managed Compliance Documentation Service

    Pricing the service requires separating three components that are sometimes bundled and should not be.

    The platform cost — vulnerability scanning, framework mapping, and artifact generation — is your per-user cost from the platform plus your markup. This is the foundation of the service and the most predictable cost element. Per-user pricing means it scales cleanly with the client’s headcount rather than fluctuating with device counts or scan scope changes.

    The reporting and documentation labor — the monthly findings review, quarterly evidence package assembly, and annual readiness preparation — is the managed service fee on top of the platform cost. This reflects the human time your team invests in interpreting findings, writing client-facing summaries, maintaining the evidence package structure, and conducting the annual review. For a client with moderate complexity, this is typically one to three hours per month of skilled labor. Priced appropriately, this layer should carry higher margins than pure platform pass-through.

    Remediation billing — the professional services work generated by open findings — is separate from both. A client who pays for the documentation service is paying for visibility and evidence. What they do with that visibility is a separate purchasing decision. Some remediation items fall within your managed services agreement. Others — significant reconfiguration, policy development, third-party assessments — are out-of-scope professional services billed at your standard rate.

    Clients who understand the structure find it straightforward: a predictable monthly fee for the managed compliance service, and project-based billing for remediation work when findings require it. The structure is clean, the value of each component is visible, and neither element subsidizes the other.

    If you want to see how the platform’s framework mapping, artifact generation, and reporting tools support the managed compliance documentation service model described here, book a 30-minute demo. We will walk through the workflow for your specific client mix and compliance framework requirements.

    → Book a Demo

    Frequently Asked Questions

    How much time does it actually take to maintain compliance documentation on a monthly basis?

    With platform tooling that handles framework mapping and report generation automatically, the human time for a moderately complex client is typically one to two hours per month for review, interpretation, and client-facing summary. Quarterly evidence package assembly runs three to four hours. Annual readiness review runs four to six hours depending on scope. The labor becomes predictable and recoverable once the process is standardized — which is the primary operational advantage over the annual scramble model, where labor spikes unpredictably and is rarely fully recovered in billing.

    How do I explain the value of monthly compliance reports to a client who thinks they only need documentation before an audit?

    The clearest explanation is to walk through what happens when documentation is assembled reactively. An auditor reviewing a package assembled in three weeks before the assessment sees date stamps that cluster around the preparation period, no evidence of continuous monitoring, and no remediation history. That pattern is a red flag, not a green light. Continuous documentation — twelve monthly reports, four quarterly packages — demonstrates an ongoing security practice. That is what assessors are looking for, and it is what insurers are asking about when they inquire about your monitoring cadence.

    Which compliance framework should I lead with when positioning this service?

    Lead with whichever framework creates the most immediate external pressure for the client segment you are targeting. For defense contractor clients, CMMC is the entry point. For healthcare, HIPAA. For clients processing payments, PCI DSS. For SaaS companies facing enterprise procurement requirements, SOC 2. The managed compliance documentation service model works for all of them — the framework just determines which evidence package structure you use and which controls you are mapping findings against. Starting with the framework the client already feels pressure around makes the service immediately relevant rather than aspirational.

    How do I handle clients who are subject to multiple frameworks simultaneously?

    Multi-framework clients are actually an argument for the managed service model, not a complication of it. A defense contractor who also processes payments faces both CMMC and PCI DSS requirements. A healthcare organization with a cloud-based EHR might face HIPAA, SOC 2 from their vendor relationship, and NIST CSF from their cyber insurance carrier. Managing those frameworks manually across separate documentation efforts is where the annual scramble gets truly painful. A platform that maps findings to multiple frameworks simultaneously means the underlying scan data serves multiple compliance purposes, and the quarterly evidence package can be structured by framework rather than requiring separate engagements for each one.

    What should the quarterly evidence package actually contain?

    The specific contents vary by framework, but the structural elements are consistent: a cover summary stating the period covered and the framework being addressed; the three monthly findings reports from the quarter; a remediation status table showing open, closed, and in-progress items with dates; a current control coverage map showing which framework controls have evidence and which have gaps; any supplementary documentation the framework requires (SSP updates for CMMC, SRA updates for HIPAA, SAQ updates for PCI); and an executive summary written for non-technical stakeholders. The package should be organized so that an auditor can find the evidence for any specific control without asking you to locate it for them.

    How do I price this service against competitors who offer a single annual assessment?

    The comparison is not quite like-for-like. A single annual assessment produces a point-in-time snapshot that is outdated the moment it is delivered. Your managed compliance documentation service produces continuous evidence that holds up under assessor scrutiny because it reflects an ongoing practice rather than a preparation sprint. The more useful comparison is against what the client would pay to do this themselves — the staff time consumed by manual evidence assembly, the cost of a rushed audit that fails on evidence quality, the premium on their insurance renewal because they cannot demonstrate continuous monitoring. Framed against those costs, a recurring managed service at a predictable monthly rate is straightforward to justify.

  • How MSPs Can Use Compliance Obligations to Open Security Conversations

    Security is a hard thing to sell on fear alone. Nobody wants to be sold to with worst-case scenarios, and experienced buyers have heard the breach statistics enough times that the numbers have lost their weight. What still lands — what opens a genuine conversation rather than a defensive response — is specificity. Not “breaches are expensive” but “your CMMC Phase 2 window closes in November and you have not started.” Not “cyber threats are rising” but “your external attack surface has three open ports your insurer is going to ask about at renewal.”

    Compliance obligations give you that specificity without any fear-mongering required. The external pressure already exists. The regulatory deadline is already set. The insurer is already asking the questions. Your job is not to manufacture urgency — it is to connect the urgency that already exists to a structured service that addresses it. That is a fundamentally different kind of conversation, and it is one that closes at a much higher rate.

    This article is a practical playbook. It covers how to identify which compliance pressure is in play for each client segment, how to open the conversation in a way that feels like advice rather than a pitch, how to use evidence without being alarmist, and how to move a prospect from a free tool or self-assessment into a booked call.

    Why Compliance Is the Right Entry Point

    Regulated organizations need real security evidence — not checkbox compliance theater. That distinction is the core of every conversation you are trying to have. A client who is checking boxes on a self-assessment without the underlying controls in place is not protected. They are exposed to assessment failure, regulatory action, and in some cases personal legal liability for executives who have signed off on attestations that do not reflect reality.

    The compliance angle works because it reframes the conversation away from abstract risk and toward concrete obligation. A client who does not feel urgency about a hypothetical breach often feels very urgent urgency about a contract they could lose, a license they could forfeit, or an insurance policy that could be voided. The compliance framework becomes the entry point; the security practice becomes the solution. And unlike fear-based pitches, compliance-based conversations have a natural scope, a natural timeline, and a natural deliverable — all of which make it easier to define what you are selling and why it is worth what it costs.

    Mapping Compliance Pressure to Client Segments

    Before you can open the right conversation, you need to know which compliance pressure is in play. Not every client faces the same external driver, and leading with the wrong framework signals that you have not done your homework. Here is how to map the pressure to the segment.

    CMMC — Defense contractors and their subcontractors

    The client profile: any business that holds a DoD contract or works as a subcontractor in the defense supply chain. CMMC Phase 1 is live. Level 2 self-assessments and SPRS submissions are required for new contracts now. C3PAO third-party certification under Phase 2 begins November 2026.

    The opening question: “Do you know whether any of your DoD contracts or subcontracts require CMMC Level 2 certification, and has your SPRS score been submitted?”

    Why it works: Most defense subcontractors either do not know their CMMC level requirement or have not completed an SPRS submission. The question surfaces a specific, concrete gap — not a vague risk — and positions you as someone who knows the regulatory landscape better than they do.

    What the conversation leads to: A gap assessment mapped to the 110 NIST 800-171 controls, a System Security Plan, and ongoing vulnerability scanning to satisfy continuous monitoring requirements. CMMC is one of the highest-value compliance entry points because the scope is specific, the timeline is mandated, and the consequence of inaction is loss of contract eligibility.

    HIPAA — Healthcare and behavioral health practices

    The client profile: medical practices, dental offices, behavioral health providers, telehealth platforms, and any business associate that handles protected health information. HIPAA enforcement has tightened considerably, with the HHS Office for Civil Rights increasing both audit frequency and penalty enforcement.

    The opening question: “When did you last complete a formal HIPAA Security Risk Assessment, and do you have documentation of that assessment you could produce if OCR contacted you?”

    Why it works: HIPAA’s Security Rule requires a documented, organization-wide security risk assessment as a matter of compliance — not a recommendation but a requirement. Most small healthcare practices have never done one formally. The question is specific, the gap is common, and the consequence of a missing assessment is both a HIPAA violation in itself and a liability exposure if a breach occurs.

    What the conversation leads to: A structured risk assessment with documented findings, ongoing vulnerability scanning, dark web and credential breach monitoring (which directly addresses the leading cause of healthcare data breaches — compromised credentials), and a compliance reporting cadence the practice can hand to their privacy officer or legal counsel.

    PCI DSS — Retailers, restaurants, and payment processors

    The client profile: any business that accepts credit cards, processes transactions, or stores cardholder data. PCI DSS 4.0 is fully in effect as of March 2025, and it introduced significant new requirements around authentication, web application security, and targeted risk analysis that caught many merchants flat-footed.

    The opening question: “Has your acquiring bank or payment processor asked you to confirm PCI DSS 4.0 compliance, and have you updated your SAQ to reflect the new requirements?”

    Why it works: The transition from PCI DSS 3.2.1 to 4.0 introduced dozens of new controls and changed how several existing ones are assessed. A client who last completed their SAQ under the old standard and has not reviewed the new requirements is potentially out of compliance without knowing it. The question is concrete and practically unanswerable without having done the review.

    What the conversation leads to: A PCI DSS 4.0 readiness review, external and internal vulnerability scanning (required under PCI DSS for all in-scope systems), web application scanning, and an annual penetration test — all of which PCI DSS 4.0 explicitly requires. PCI is particularly useful because the requirements for scanning and penetration testing are spelled out at a granular level, making the scope of your service easy to define and justify.

    SOC 2 — SaaS companies and professional services firms handling client data

    The client profile: software companies, managed service providers, financial advisors, legal firms, accounting practices — any organization that processes client data and is starting to face enterprise customer requirements for a SOC 2 report.

    The opening question: “Are you getting SOC 2 questionnaires from prospects or enterprise customers, and do you have a current SOC 2 report you can provide?”

    Why it works: Enterprise procurement increasingly requires SOC 2 Type II reports as a condition of vendor approval. A growing company without one is losing deals to competitors who have it, and they often do not know how far behind they are in the preparation timeline. The question surfaces a revenue impact — not just a compliance gap — which makes the urgency immediate.

    What the conversation leads to: SOC 2 readiness assessment, continuous vulnerability scanning to satisfy the availability and security trust service criteria, evidence generation for the audit, and an ongoing security monitoring engagement that supports annual recertification. SOC 2 clients tend to be higher-value and longer-tenure because the compliance relationship is annual and recurring.

    How to Use Evidence Without Sounding Alarmist or Gimmicky

    There is a version of this conversation that goes wrong fast: running a free scan on a prospect’s domain before you have a relationship, finding open ports, and calling them to say “we found serious vulnerabilities in your network.” That approach feels like a shake-down, not a consultation. Even if the vulnerabilities are real and the concern is genuine, leading with gotcha evidence before earning trust produces defensiveness, not engagement.

    The right approach is to use evidence as a conversation opener, not a closing pressure tactic. That distinction changes the framing entirely.

    When you use free tools proactively — running an external scan on a prospect’s domain, checking their dark web exposure, reviewing their email authentication posture — frame the results as information you want to share, not a problem you are threatening them with. “We ran a quick external check on your domain as part of our outreach — a few things came up that I wanted to walk you through” is a very different opening than “your network has critical vulnerabilities.” One sounds like a peer sharing intel. The other sounds like a vendor trying to scare someone into a sale.

    The goal of evidence in the opening conversation is to demonstrate competence and to move the prospect from abstract to specific. They knew vaguely that security was a concern. Now they know specifically that their SPF record is misconfigured, that two executive email addresses appeared in a breach dataset, and that their external SSL certificate expires in six weeks. Those are concrete, addressable items. That conversation is easier to have, easier to scope, and easier to close than “you should really think about your security posture.”

    The discipline here is to present findings factually, without editorializing about catastrophe, and to connect each finding to a specific compliance obligation or business risk rather than to a worst-case scenario. “Your DKIM record is not configured, which means your email domain can be spoofed — that is directly relevant to your HIPAA Security Rule requirements around information integrity” is more credible than “you could get hacked.” The first positions you as knowledgeable. The second positions you as someone trying to sell something.

    → The free security tools page gives you a set of purpose-built external check tools — external scan, dark web breach check, SSL analyzer, SPF/DKIM/DMARC checker, DNS audit, HTTP security headers, and a security posture scorecard — that produce evidence you can share without requiring any internal access to the prospect’s environment.

    A Mini Outreach Framework: From Cold to Conversation

    The most effective compliance-based outreach follows a three-step pattern: identify the pressure, run the relevant check, personalize the opener.

    Step 1 — Identify the compliance pressure in play. Before reaching out, know which framework is most relevant to this prospect. For a medical practice, it is HIPAA. For a defense subcontractor, it is CMMC. For a SaaS company being asked about it by enterprise customers, it is SOC 2. Your vertical data and LinkedIn research should tell you which pressure to lead with. If you are not sure, the opening question surfaces it.

    Step 2 — Run the relevant free check. Use the free external scan and email authentication tools to build a picture of their external posture before the first contact. This takes about five minutes per prospect and gives you specific, factual information to reference in your outreach. You are not making claims — you are sharing what you found.

    Step 3 — Personalize the opener with a single specific finding and a compliance hook. The cold email or call opener does not need to be long. It needs to be specific and relevant. Here are examples for each framework.

    CMMC opener: “I noticed your company works in the defense supply chain — with CMMC Phase 2 C3PAO requirements starting in November, I wanted to reach out. We ran a quick external check on your domain and a few things came up that are worth a 15-minute conversation. Happy to walk through what we found.”

    HIPAA opener: “I work with a number of healthcare practices in [region] on HIPAA Security Rule compliance. We ran an external posture check on your practice and found [specific finding — e.g., your email domain is missing DMARC policy, which is a risk for business email compromise]. Given where OCR enforcement is heading, I thought it was worth a quick call.”

    PCI DSS opener: “With PCI DSS 4.0 fully in effect, a lot of merchants are discovering their previous SAQ no longer covers the new authentication and web app requirements. We ran a quick external check on your site and had a couple of things I wanted to share. Do you have 15 minutes this week?”

    SOC 2 opener: “We work with a lot of SaaS companies who are starting to field SOC 2 questionnaires from enterprise prospects. We ran a quick external check on your domain — a few findings came back that would be worth addressing before a SOC 2 audit. Happy to walk you through what we found if you have 15 minutes.”

    Notice what each opener has in common: it references a real external finding, it anchors to a specific compliance framework the prospect recognizes, and it asks for a short, low-commitment next step. None of them say “you are at risk of a breach.” None of them promise to fix everything. They simply demonstrate that you know the prospect’s regulatory environment and that you have already done a small piece of relevant work on their behalf.

    How to Move From a Free Tool or Self-Assessment Into a Booked Call

    Free tools and self-assessments work as lead conversion mechanisms only if there is a frictionless path from the tool output to a conversation. The failure mode for most free tools is that a prospect completes the assessment, gets a score, and then closes the browser because there is no clear next step that feels relevant to what they just learned.

    The five-minute security self-assessment that produces a branded report is a particularly effective conversion mechanism for exactly this reason: the output is specific to the prospect’s answers, it generates a posture score, and it identifies the areas where their exposure is highest. The report itself creates the opening for a follow-up call because it gives the prospect something concrete to discuss — not a generic pitch, but their own results.

    The follow-up framework after a tool or assessment completion should work like this.

    Immediate: If the tool is gated behind an email capture, the follow-up email goes out within the same business day — ideally within a few hours. The email references the specific results: the posture score, the highest-risk areas the assessment surfaced, and a single compliance hook relevant to their industry. It ends with a direct ask for a 20-minute call to walk through what the results mean and what addressing the gaps would involve.

    Day 2 follow-up: If there is no response to the first email, a brief second touchpoint reinforces the compliance timeline. “The assessment flagged a few items that are directly relevant to your [CMMC / HIPAA / PCI DSS] obligations — wanted to make sure you had a chance to see them before [deadline or renewal event].” One specific, actionable ask: “Are you available for 20 minutes on [specific day]?”

    The call itself: The goal of the first call is not to close a security agreement. It is to confirm the compliance pressure, walk through the assessment results, and determine whether there is a gap that you can help close with a defined scope of work. A prospect who gets on a call having seen their own posture score and understands their compliance timeline is already primed to discuss specifics. The call is about scoping, not persuading.

    The important discipline here is to treat the tool results as evidence in a consultation, not ammunition in a sales pitch. “Your assessment shows that your email authentication is not configured — that directly impacts your HIPAA risk posture and is something we can resolve in about a week” is a more credible and actionable statement than “your security is in bad shape and you need to act now.” The first tells the prospect what is wrong, why it matters, and how fast it can be addressed. The second creates alarm without a path forward.

    The Sales Collateral That Supports Each Compliance Conversation

    Each compliance framework conversation benefits from a different piece of leave-behind or follow-up collateral. The goal is to give the prospect something they can share internally — with their office manager, their legal counsel, their CFO — that reinforces the compliance obligation and the business case for addressing it.

    For CMMC conversations, the CMMC 2.0 Readiness Guide is the right leave-behind. It gives defense contractors a plain-language breakdown of what each level requires, what Phase 2 means for their specific situation, and what the preparation timeline looks like. A client who reads it before the next call arrives educated, not cold.

    For clients who are primarily cost-sensitive and need to understand the financial case for security investment, the Cost of a Breach Calculator frames the conversation in terms they can bring to a leadership discussion. It is not alarmist — it is a structured way to compare the cost of a breach against the cost of prevention, which is a budget conversation, not a fear conversation.

    For clients who are already managed services customers and need to be introduced to security as an add-on, the QBR Security Slide Deck is a five-slide insert that fits into an existing quarterly business review and sets up the security upsell conversation naturally, without requiring a separate meeting.

    For your team, the Objection Handling Playbook documents the ten most common objections MSPs encounter when pitching security services to existing managed services clients — and the word-for-word responses that have worked in actual partner conversations. The objections are predictable. The answers should be rehearsed.

    To see how SentinelCommand supports security assessments, compliance mapping and reporting, book a demo.

    → Book a Demo

    Frequently Asked Questions

    What if I do not know which compliance framework applies to a prospect before the first call?

    A few minutes of research before outreach usually answers the question. LinkedIn and the company website tell you their industry vertical. Government contractor status is often publicly listed. Healthcare and financial services verticals map predictably to HIPAA and relevant financial regulations. If you are still not sure, the opening question — “Who is asking you to prove security compliance right now?” — surfaces it in the first 60 seconds of any conversation. You do not need to know before you reach out; you need to know before you scope.

    How do I handle a prospect who says they are already compliant?

    The follow-up question is: “What does that look like for you — do you have a documented assessment and evidence package, or is it more of an internal review?” Most clients who say they are compliant have done some form of self-assessment but have not done the technical verification that produces audit-ready evidence. The distinction is important, and surfacing it gently — without implying they have been doing it wrong — is usually enough to open the next level of conversation. “That makes sense. A lot of our clients are in the same position — they know what they are supposed to have but are not confident what an auditor or assessor would actually accept as proof.”

    How do I use free tools without it feeling intrusive or presumptuous?

    Frame it as a professional courtesy, not surveillance. The external tools check only publicly available information — what any external party can see about a company’s domain, email configuration, and SSL posture. This is the same information a threat actor can see. Sharing it with a prospect is a demonstration of competence, not a violation of privacy. The framing matters: “We run a quick external check on every prospect we reach out to — it helps us make sure the conversation is relevant to what you are actually facing” normalizes the practice and positions it as part of your standard process rather than something targeted specifically at them.

    What if a prospect completes the self-assessment but does not respond to follow-up?

    Two follow-up touches within the first week are appropriate. After that, a longer-cycle nurture sequence — compliance deadline reminders, framework updates, relevant resources — keeps the relationship warm without being aggressive. Compliance timelines have a way of creating urgency on their own schedule. A prospect who was not ready to engage in January will often reach out in September when their renewal is imminent or their prime contractor starts asking questions. Having touched them with relevant, non-pushy content in the interim means you are the first call they make when the urgency arrives.

    How do I transition an existing managed services client into a security conversation without it feeling like a sales call?

    Use the QBR as the container. The quarterly business review is already a structured conversation about business outcomes. A five-slide security insert that covers the client’s current compliance obligations, what the evidence standard requires, and what their current posture looks like against that standard fits naturally into that context. You are not introducing a new conversation — you are adding a new section to a conversation that already exists. The transition from “here is what we managed this quarter” to “here is what your compliance exposure looks like and what we should be doing about it” is a logical extension of the relationship, not a pivot into selling mode.

    How do I explain compliance services to a client who thinks they are too small to be a target?

    Redirect from targeting to obligation. The compliance requirement exists regardless of whether the client believes they are a likely target. HIPAA does not exempt small medical practices. CMMC does not exempt small defense subcontractors. PCI DSS does not exempt restaurants that process fewer than a million transactions per year. The compliance obligation is based on what data they handle and what contracts they hold, not on how large or prominent they are. The frame that works best: “The regulation does not care about your size. It cares about the data you hold and the contracts you have signed. The obligation is the same whether you have five employees or five hundred.”

  • Vulnerability Scanning vs. Penetration Testing: What Your Clients Are Confused About and How to Clarify It

    Every MSP account manager has been in this conversation. A client gets a cyber insurance renewal questionnaire, sees the words “vulnerability assessment” and “penetration test,” and calls you to ask whether they need both or just one. Or they come in having already Googled it and now believe a penetration test is simply a more thorough version of a scan. Or they think they had a penetration test last year because someone ran a tool against their network for an hour and emailed them a PDF.

    The confusion is understandable. The security industry uses the terms inconsistently, vendors often use them interchangeably to sell assessments, and non-technical buyers have no reliable way to know the difference from marketing materials alone. That leaves your team holding the explanation — and if you get it wrong, you either undersell a client who needs a pen test or oversell one who needs a scan.

    This article gives you a clear, practical way to explain the difference to a non-technical buyer, and a framework for knowing which service to recommend when.

    What Vulnerability Scanning Actually Is

    Vulnerability scanning is an automated, ongoing process of checking a system against a known database of vulnerabilities — misconfigurations, unpatched software, exposed services, weak credential policies, and similar conditions that are known to create risk. The scanner compares what it finds in the environment against what is known to be dangerous, flags the matches, and produces a prioritized list of findings.

    The key words are “automated” and “ongoing.” A scan does not require a human attacker to execute. It does not test whether a vulnerability can actually be exploited in this specific environment by a real adversary under real conditions. What it does is give you a continuous, up-to-date picture of the attack surface — what is exposed, what is unpatched, and what has changed since the last scan.

    That ongoing cadence is what makes scanning genuinely useful as a managed service. A point-in-time scan taken in January tells you the posture in January. A new device deployed in March, a patch missed in April, a cloud storage bucket misconfigured in May — none of those appear in the January snapshot. Running scanning monthly, weekly, or daily gives you and your clients a live view of drift, not a historical record of a moment that has already passed.

    Modern vulnerability scanning also extends beyond the internal network. Web application DAST scanning checks client-facing applications for OWASP-class vulnerabilities — injection, authentication weaknesses, exposed APIs, insecure configurations — using the same automated methodology applied externally. External network scanning checks what an attacker could see and reach from the internet without any internal access. Together, these cover the attack surface a client’s auditor, insurance carrier, or assessor is most likely to scrutinize.

    What a Penetration Test Actually Is

    A penetration test is a scoped, time-limited engagement in which a qualified tester — a human being with offensive security skills — attempts to exploit vulnerabilities in a client’s environment using techniques that a real attacker would use. The tester is not just running tools. They are making judgment calls about which findings to chain together, which social engineering approaches to try, how to escalate access once an initial foothold is obtained, and what the actual business impact of a successful breach would be.

    The output of a penetration test is not a list of potential vulnerabilities. It is a documented account of what an attacker was actually able to do, how they did it, what they were able to access, and what the realistic business consequence of a real attack would be. That is a fundamentally different kind of evidence than a scan report.

    Penetration tests are scoped by type. An external network penetration test attempts to compromise systems accessible from the internet. An internal network penetration test simulates what a threat actor could do after gaining a foothold inside the network — which is the scenario that matters for insider threats, phishing compromises, and lateral movement after an initial breach. A web application penetration test goes deeper than DAST scanning by combining automated tooling with manual exploitation attempts, logic flaw testing, and authenticated testing of application-layer controls. Each type answers a different question about a different threat scenario.

    Side-by-Side: Vulnerability Scanning vs. Penetration Testing

    ComparisonVulnerability ScanningPenetration Testing
    Primary goalIdentify and track known weaknesses across the attack surfaceDetermine what an attacker can actually do by exploiting those weaknesses
    How it worksAutomated tool checks systems against a vulnerability databaseQualified human tester attempts to exploit vulnerabilities using real attack techniques
    CadenceContinuous — monthly, weekly, or daily depending on tierPeriodic — typically annual, or event-driven (before an audit, after a major change)
    DepthBroad coverage across all discovered assets; identifies potential vulnerabilitiesNarrow scope, deep exploitation — confirms which vulnerabilities are actually exploitable and to what consequence
    Human judgment requiredNo — automated discovery and matchingYes — chaining vulnerabilities, escalating access, assessing real business impact
    Primary outputPrioritized vulnerability list with remediation guidance, mapped to compliance frameworksNarrative report of attack path, what was accessed, and business impact of a real breach
    Compliance valueSatisfies continuous monitoring requirements under CMMC, HIPAA, PCI DSS, NIST CSF, SOC 2Often required separately for audits, insurance underwriting, or pre-certification assessments
    Cost modelPredictable recurring — per user, per monthProject-based — scoped per engagement
    When to recommendEvery compliance-obligated client, alwaysClients facing audits, regulatory scrutiny, insurance requirements, or major environment changes

    The Analogy That Actually Works in Client Conversations

    For non-technical buyers, analogies land better than technical definitions. Here is one that consistently works in practice.

    Think of vulnerability scanning as a building inspection — a systematic walk-through that identifies every unlocked door, broken window, faulty lock, and structural weakness. It covers everything, it happens regularly, and it produces a punch list of what needs to be fixed.

    A penetration test is a red team exercise — you hire someone to actually try to break in. They look at the building, find the weakest point, test whether they can get through it, and report back on what they were able to access once inside. The building inspector told you the window latch was weak. The red team tells you that a motivated intruder with basic tools got in through that window in six minutes and was able to access the server room.

    Both services are useful. The inspection tells you what to fix. The red team exercise tells you what happens if you do not fix it — and which things to fix first. Neither service replaces the other.

    The Mistake MSPs Make When Explaining This

    The most common mistake is positioning these services as alternatives — telling a client they can choose one or the other based on budget. That framing is wrong in both directions.

    A client who only has a penetration test but no ongoing scanning is flying blind between engagements. The pen test captures a moment in time. By the next quarter, new vulnerabilities have been published, patches have been missed, new services have been exposed, and the attack surface has changed. The pen test finding from March does not tell you what your exposure looks like in November.

    A client who only has vulnerability scanning but no penetration test knows what the risks look like on paper but has no evidence of actual exploitability. Their auditor, their insurer, or their prime contractor may specifically require a penetration test to confirm that the most critical vulnerabilities have been validated and that the remediation effort is reducing real risk — not just reducing a number in a scan report.

    The services address different questions. Scanning answers: what is exposed? Pen testing answers: what can an attacker actually do with what is exposed? A mature security posture requires answers to both.

    When You Should Recommend Both

    There are specific situations where recommending both services in the same conversation is not upselling — it is giving the client accurate advice about what they need.

    Before a compliance certification or formal audit. Whether it is a CMMC C3PAO assessment, a SOC 2 audit, or a PCI DSS QSA review, assessors will often ask for both a vulnerability scan history and a penetration test report. The scan history demonstrates ongoing monitoring. The pen test demonstrates that the client has validated their most critical exposures. Having only one of the two documents creates gaps in the evidence package.

    At cyber insurance renewal. Insurers have materially tightened their technical questionnaires over the past two years. Many now require applicants to confirm both that they run vulnerability scanning and that they have completed a penetration test within the past twelve months. A client who cannot answer yes to both may face higher premiums, reduced coverage, or outright declination. If your client is coming up on renewal without a recent pen test, that is a conversation to have before the insurer asks the question.

    After a significant infrastructure change. When a client migrates to a new cloud environment, deploys a major new application, or makes material changes to their network architecture, the existing scan baseline no longer reflects the new attack surface — and no previous pen test has validated the new environment’s resistance to exploitation. A targeted penetration test after a significant change is a sensible safeguard, not an optional luxury.

    When a client handles highly sensitive data. Healthcare organizations with large patient data footprints, defense contractors handling CUI, financial firms with client account data — these clients carry heightened consequence if a breach occurs. For them, the question is not whether a penetration test is warranted but how often and how deep. Annual external and internal penetration testing alongside continuous scanning is the baseline expectation in regulated environments at this sensitivity level.

    When a client has remediated significant findings. After a major remediation effort — patching a backlog, reconfiguring access controls, migrating to a new authentication system — a penetration test serves as a validation that the remediation actually closed the gaps that mattered. Scan data will show the findings resolved. A pen test confirms the fixes hold under adversarial pressure.

    → The Partner Program page covers how partners can add penetration testing as a separate buying motion — positioned as a distinct, higher-scrutiny engagement that complements recurring platform scanning rather than competing with it.

    How to Structure the Conversation With a Non-Technical Buyer

    When a client asks whether they need a vulnerability scan or a penetration test, the most useful starting question is: “What is driving the question — is someone asking you to prove something specific?”

    If the answer is a compliance framework requirement, a cyber insurance renewal, or an audit, the follow-up is to find out exactly what the requirement says. Most compliance frameworks specify which type of assessment is required, how frequently, and what the output documentation needs to include. That tells you which service satisfies the requirement and whether both are needed.

    If the answer is general anxiety about security posture — “we just want to know if we are protected” — the right framing is that scanning gives them ongoing visibility into their exposure, and penetration testing tells them what an attacker would actually be able to do. Most clients who are asking this question genuinely need both, but starting with scanning establishes the baseline and creates the evidence the penetration test can validate.

    If the client is purely budget-driven and can only start with one, the honest answer is that ongoing scanning is the higher-priority foundation. A penetration test taken without any scan data to contextualize it against produces findings that are harder to remediate systematically. Scanning first, penetration testing second, is the logical sequence.

    If you want to see how the platform’s scanning tiers — from monthly at Baseline to daily at Supreme — map to compliance requirements, and how penetration testing add-ons are structured for partners, book a 30-minute demo. We will walk through both service motions with your specific client mix in mind.

    → Book a Demo

    Frequently Asked Questions

    Can a vulnerability scan replace a penetration test for compliance purposes?

    Generally no — and it depends on what the compliance requirement actually says. Most frameworks that require penetration testing specify it as a distinct requirement from vulnerability scanning, not an alternative to it. PCI DSS 4.0, for example, requires both internal and external vulnerability scanning and a separate annual penetration test. CMMC and SOC 2 similarly treat ongoing scanning and point-in-time penetration testing as complementary controls rather than interchangeable ones. Before telling a client that their scanning satisfies a penetration testing requirement, confirm exactly what the relevant standard requires.

    How often should clients have a penetration test done?

    Annual is the minimum for most compliance frameworks and cyber insurance carriers. For clients in high-sensitivity environments — defense contractors handling CUI, healthcare organizations, financial firms — annual external and internal testing is a reasonable baseline. Event-driven testing on top of annual testing is appropriate after significant infrastructure changes, major application deployments, or material changes to the network architecture. The frequency should be anchored to what the client’s compliance framework or insurer requires, not to a generic schedule.

    What is DAST scanning and how is it different from a web application penetration test?

    DAST — Dynamic Application Security Testing — is automated scanning of a web application from the outside, checking for common vulnerability classes like injection, authentication weaknesses, and misconfigurations. It covers broad surface area quickly and runs on a repeating schedule. A web application penetration test goes deeper: a human tester is checking for logic flaws that automated tools miss, testing authenticated workflows, chaining vulnerabilities together, and attempting to escalate access in ways a real attacker would try. DAST scanning gives you ongoing detection of known vulnerability patterns. A web application pen test gives you a validated picture of what a skilled attacker could actually accomplish against the application. They answer different questions at different levels of depth.

    My client already had a penetration test from another firm. Do they still need ongoing scanning?

    Yes. A penetration test is a point-in-time assessment. The moment the engagement ends, the environment starts drifting — new vulnerabilities are published, patches are missed, configurations change, new services get exposed. A pen test from six months ago tells you what the attack surface looked like six months ago. Ongoing vulnerability scanning tells you what it looks like today. The prior penetration test is useful as a baseline and for compliance documentation. It does not replace the need for continuous monitoring between now and the next scheduled test.

    How should I explain the difference in pricing between the two services?

    The pricing model reflects the nature of each service. Vulnerability scanning is predictable and recurring — a per-user, per-month cost that scales with the client’s headcount and runs continuously. Penetration testing is a scoped project — a qualified tester spends a defined number of hours attempting to exploit the environment, and the price reflects the scope, depth, and type of test. Framing it this way to a client makes the difference intuitive: one is an ongoing subscription for continuous visibility, the other is a periodic engagement for validated depth. Both are legitimate line items, and neither replaces the other.

    What should a client expect to receive from a penetration test?

    A professional penetration test report should include an executive summary written for non-technical leadership — what was attempted, what succeeded, what the business impact would be in a real attack — and a technical findings section that documents each vulnerability exploited, the attack chain used, evidence of exploitation, and specific remediation guidance. Findings should be rated by severity and exploitability, not just by CVSS score in isolation. The report should be clear enough that someone who did not watch the engagement unfold can understand what happened, why it matters, and what to do about it. If a client receives a report that is effectively a formatted scan output with a penetration test label on it, they did not receive a penetration test.

  • CMMC 2.0 Explained: What MSPs Serving the Defense Industrial Base Need to Know

    CMMC 2.0 is no longer a future event. Phase 1 became enforceable on November 10, 2025, when the Department of Defense published the 48 CFR Final Rule. New DoD solicitations can now require CMMC compliance as a condition of award — and Phase 2, which mandates third-party C3PAO certification for Level 2 contractors handling Controlled Unclassified Information, takes effect November 10, 2026.

    If you manage IT for any business in the defense supply chain — prime contractors, subcontractors, or anyone whose work touches Federal Contract Information or CUI — your clients are already affected. The question for your MSP is not whether CMMC matters. It is whether you are positioned to help your clients respond to it, or whether they are about to find an MSP that is.

    This article is for MSPs serving the Defense Industrial Base. It covers what CMMC actually requires, what the enforcement timeline means operationally for your clients, and what you need to deliver to be a credible security partner rather than a bystander during a compliance scramble.

    What CMMC 2.0 Actually Is (and What It Replaced)

    CMMC 2.0 is the DoD’s mechanism for verifying that defense contractors have actually implemented the cybersecurity practices they are required to have under existing federal acquisition regulations — specifically DFARS 252.204-7012, which has required contractors to meet NIST SP 800-171 since 2017. The problem CMMC is solving is that self-attestation under the old model was widely ignored. The DoD estimates that a significant portion of the Defense Industrial Base is not in compliance with NIST 800-171 requirements they have technically been obligated to meet for nearly a decade.

    CMMC 2.0 simplified the original five-level CMMC 1.0 framework into three levels and aligned more directly with existing NIST standards. The three levels work as follows.

    Level 1 (Foundational) applies to contractors handling only Federal Contract Information — basic administrative or logistical data. It requires annual self-assessment and affirmation of compliance with 15 practices drawn from FAR clause 52.204-21. This is the floor, not the ceiling, and it is already in effect under Phase 1.

    Level 2 (Advanced) applies to contractors handling Controlled Unclassified Information. It requires compliance with all 110 security requirements in NIST SP 800-171 Revision 2. Under Phase 1, some Level 2 contracts allow self-assessment with SPRS submission and annual executive affirmation. Beginning November 10, 2026, most Level 2 contracts will require third-party certification by a C3PAO — a Certified Third-Party Assessment Organization. Contractors who have not started preparing now face a readiness window measured in months, not years.

    Level 3 (Expert) applies to contractors on the highest-priority DoD programs handling the most sensitive CUI. It requires compliance with NIST SP 800-172 in addition to all Level 2 requirements and will be assessed by the Defense Industrial Base Cybersecurity Assessment Center. Level 3 requirements begin appearing in contracts under Phase 3, which starts November 10, 2027.

    The Enforcement Timeline MSPs Need to Track

    The phased rollout does not mean contractors can wait. The DoD has made clear that Phase 1 requirements apply to new solicitations issued after November 10, 2025, and that prime contractors are already pushing Level 2 requirements down to subcontractors even before the Phase 2 mandatory date. A subcontractor who does not have an active SPRS submission and a documented compliance posture is already at risk of being excluded from bids under primes who are enforcing the requirement early.

    The Department of Justice has also made the stakes explicit. The Civil Cyber Fraud Initiative, using the False Claims Act as its enforcement tool, resulted in more than $52 million in cybersecurity-related recoveries in 2025 alone — a more than threefold increase from the prior year. Contractors who falsely attest compliance in SPRS without the supporting controls in place face potential civil and criminal liability that goes beyond losing a contract. That context should inform every client conversation you have about why this is not a checkbox exercise.

    The practical window for your clients is narrower than the calendar suggests. Achieving Level 2 readiness — implementing 110 NIST 800-171 controls, documenting a System Security Plan, completing a Plan of Action and Milestones for any gaps, and passing a C3PAO assessment — typically requires six to twelve months of focused work for organizations that are starting with a meaningful gap. Most DIB contractors are. Accorian’s 2026 readiness analysis found that roughly 1% of contractors are currently considered audit-ready. Your clients are almost certainly in that other 99%.

    Framework Checkbox Talk vs. Practice-Level Readiness

    The most common mistake MSPs make when approaching CMMC is treating it as a documentation project rather than an operational security project. It is tempting to point a client at a framework checklist, have them self-attest the controls they believe they have in place, and call that CMMC readiness. That approach has two serious problems.

    The first problem is that self-attestation without evidence is a False Claims Act risk, not a compliance posture. What the DoD and C3PAO assessors are looking for is not a signed document saying a control is in place. They are looking for evidence — configurations, logs, policies, audit records, and technical proof — that demonstrates the control is actually implemented and operating as intended. For each of the 110 Level 2 practices, a contractor typically needs two distinct pieces of evidence. The gap between “we have a policy that says we do this” and “here is the technical evidence that we actually do this” is where most clients are exposed.

    The second problem is that generic framework presence is not the same as practice-level alignment. CMMC practices are specific. Access Control practice AC.L2-3.1.2, for example, requires limiting system access to the types of transactions and functions authorized users are permitted to execute — not just having a general access control policy. Each practice maps to specific technical implementations that can be verified. An MSP who tells a client they are “NIST-aligned” because they have endpoint protection and a firewall is not giving them accurate compliance information. They are setting them up for a failed assessment and potential legal exposure.

    Practice-level readiness means your client can demonstrate, for each applicable CMMC practice, what control is in place, how it is implemented technically, and what evidence exists to prove it. That is a fundamentally different engagement than filling out a checklist.

    What You Actually Need to Deliver as an MSP

    For MSPs serving DIB clients, CMMC readiness breaks into four operational components. Understanding what each requires will tell you whether your current tooling and process can support a defensible engagement.

    Vulnerability scanning and external exposure monitoring. The technical baseline. You need to know what is on the network, what is exposed, and what is unpatched. This is the starting condition for any gap analysis. Without continuous scanning, you are working from a snapshot that is outdated the moment you take it. CMMC practices under the Risk Assessment and System and Communications Protection domains require ongoing assessment, not annual reviews.

    Control gap mapping against specific CMMC practices. This is where the real work is. A gap analysis maps what your client currently has implemented against what each CMMC practice requires, identifies the delta, and produces a prioritized remediation list. The output is not a color-coded spreadsheet. It is a structured System Security Plan and a Plan of Action and Milestones that a C3PAO assessor can review. If your tooling cannot map scan findings and configuration data directly to specific CMMC practices at the control level, you are building that mapping manually — and manual is slow, inconsistent, and hard to maintain as the environment changes.

    Remediation prioritization and evidence generation. Once the gaps are mapped, remediation needs to be prioritized by risk and by what C3PAO assessors are most likely to scrutinize. Not every gap carries the same weight. Gaps in access control, configuration management, and audit and accountability tend to receive the closest scrutiny in Level 2 assessments. Your remediation plan needs to sequence the work in a way that gets the highest-risk gaps closed before the assessment window, while generating audit artifacts — logs, configuration records, access control documentation — that serve as evidence during the assessment itself.

    Client communication and ongoing compliance posture. CMMC is not a one-time assessment. Level 2 certification under Phase 2 requires annual executive affirmation and periodic reassessment. The System Security Plan and POA&M need to be living documents. Changes to the client’s system — new cloud services, personnel changes, software additions — can affect the scope of the CMMC assessment and need to be tracked. Your client communication around compliance needs to be structured enough that the client understands what changed, why it matters, and what action is required.

    Why CMMC Is a Sharp Entry Point Into Broader Security Services

    Beyond the compliance obligation itself, CMMC creates a durable service opportunity for MSPs who get in front of it. Here is why it is a particularly good entry point compared to other compliance frameworks.

    The urgency is externally imposed. You do not have to convince a client that security matters in the abstract. The DoD is creating the urgency for you. A client who stands to lose contract eligibility because their SPRS submission is missing or their gap assessment has never been done is already motivated. The conversation starts from a concrete business risk, not a hypothetical one.

    The scope expands naturally. A client who engages you for CMMC readiness work quickly discovers that the same controls that matter for CMMC — access control, audit logging, configuration management, incident response — are the same controls that matter for cyber insurance, HIPAA if they have any health-adjacent data, and basic IT hygiene. The CMMC engagement surfaces gaps that open conversations about ongoing security monitoring, dark web credential monitoring, and recurring compliance reviews. The initial engagement funds the entry; the recurring practice funds the growth.

    The evidence standard creates recurring demand. Unlike compliance frameworks where a client can check a box and move on, CMMC evidence requirements create ongoing work. Annual executive affirmations require up-to-date SSPs. C3PAO assessments require current evidence. Configuration changes require documentation updates. That is recurring billable engagement attached to a regulatory requirement that is not going away.

    The competitive window is open now. Because most MSPs have not yet built a structured CMMC practice, there is a meaningful first-mover advantage in most regional markets. A defense-sector MSP case study from partners working with the Sentinel platform found that delivering structured CMMC readiness assessments with control gap mapping and remediation prioritization — rather than generic security reviews — directly improved client retention and created referral pathways within the defense contractor community. Compliance circles are small and word travels fast.

    → See how Sentinel’s CMMC depth compares to typical platform approaches, including the difference between framework presence and practice-level alignment.

    What to Do Now If You Have DIB Clients

    The practical starting point is knowing where your clients actually stand. Not where you think they stand, and not where they think they stand — where the evidence shows they stand against the 110 NIST 800-171 controls that map to CMMC Level 2.

    The first step is identifying which of your clients handle CUI and which handle only FCI. That determines whether they need Level 1 self-assessment or Level 2 preparation. Some clients will not know the answer without your help, because the distinction requires them to understand what data flows through their systems in the context of their DoD contracts.

    The second step is running a structured gap assessment — not a self-reported questionnaire, but a technical assessment that maps their actual configuration and control state against CMMC practices. The output should be a documented gap list with remediation priority and an estimate of what closing each gap requires in time and resources.

    The third step is having a direct conversation with your client about the Phase 2 timeline. November 10, 2026 is not far from here. For a client who has never had a formal assessment, six months of remediation work before the Phase 2 deadline means starting now. That conversation should be grounded in specifics — which controls are open, what is required to close them, and what the cost of inaction is in terms of contract eligibility.

    If you want to see how the Sentinel platform maps findings to specific CMMC practices — not just framework presence, but practice-level control alignment with evidence generation — book a 30-minute demo. We will walk through the compliance workflow with your client base in mind and show you what a structured CMMC readiness engagement looks like from the MSP side.

    → Book a Demo

    Frequently Asked Questions

    What is the difference between CMMC Level 1 and Level 2 for an MSP’s clients?

    Level 1 applies to contractors handling only Federal Contract Information — basic data related to a government contract, such as administrative records or logistics information. It requires annual self-assessment against 15 baseline practices. Level 2 applies to contractors who handle Controlled Unclassified Information — more sensitive data related to DoD programs, research, or technology. It requires compliance with all 110 practices in NIST SP 800-171 and, starting November 2026 under Phase 2, third-party certification by a C3PAO. The practical difference for an MSP is the depth of evidence, documentation, and technical control required. Level 2 is a materially more demanding engagement than Level 1.

    My client says they have already been “NIST-compliant” for years. Does that mean they are CMMC ready?

    Not necessarily, and in many cases not at all. NIST SP 800-171 compliance has technically been required since 2017 under DFARS 252.204-7012, and the DoD’s own estimates suggest that the majority of the DIB has not fully implemented it. A client who has checked boxes on a self-assessment without technical verification of the underlying controls is not CMMC-ready — they are exposed to both assessment failure and False Claims Act liability if they have attested compliance in SPRS without supporting evidence. The right response is a technical gap assessment, not a self-report review.

    What is SPRS and why does it matter?

    SPRS stands for Supplier Performance Risk System. Under Phase 1, Level 1 and Level 2 contractors must submit their self-assessment scores and executive affirmations to SPRS as a pre-award condition for new DoD contracts. Contracting officers check SPRS submissions before awarding contracts. A missing or outdated SPRS entry can disqualify a contractor from a bid entirely, regardless of their actual security posture. Helping your clients understand what SPRS requires and keeping their submissions current is a direct, tangible service you can offer as part of a CMMC readiness engagement.

    Do subcontractors have to comply with CMMC, or only prime contractors?

    CMMC requirements flow down through the supply chain. If a subcontractor receives, processes, or stores CUI as part of their work on a defense contract, they are subject to the same CMMC requirements as the prime contractor. The DFARS rule includes explicit flowdown clauses requiring primes to pass CMMC obligations down to subcontractors handling applicable data. In practice, major primes like Lockheed Martin and Boeing are already requiring Level 2 compliance from subcontractors even before the Phase 2 mandatory date. Your clients who are subcontractors should not assume they have more time than the prime they work under is giving them.

    How long does it realistically take to prepare a client for a C3PAO assessment?

    For a client starting with significant gaps — which most DIB contractors have — six to twelve months is the realistic preparation window for Level 2 C3PAO readiness. That time covers technical remediation, documentation of controls in a System Security Plan, closure or mitigation of items on the Plan of Action and Milestones, and a pre-assessment readiness review. Clients who wait until late 2026 to start will not be assessment-ready by the Phase 2 deadline. The cost of that delay is not just a failed assessment — it is potential loss of contract eligibility while they work through remediation.

    Can I offer CMMC readiness services without being a C3PAO myself?

    Yes. MSPs are not required to be C3PAOs to deliver CMMC readiness services. The C3PAO performs the formal certification assessment — that is a distinct and regulated function. Your role as an MSP is to help the client get ready for the assessment: gap analysis, remediation implementation, evidence generation, SSP documentation, and ongoing compliance maintenance. That is a substantial and valuable engagement in its own right, and it positions you as the trusted partner who knows the client’s environment when assessment time arrives. Some MSPs also partner with C3PAOs to manage the formal assessment piece while retaining the ongoing security relationship.

  • MSP Security Pricing: How to Stop Bundling Security and Start Billing for It

    If you have any compliance-obligated clients — healthcare practices, defense subcontractors, financial firms, professional services firms under cyber insurance pressure — you are almost certainly delivering security-adjacent work inside your standard managed-services agreement. Monitoring alerts. Reviewing findings. Running occasional scans. Handling the compliance questions that come in around renewal time.

    And in a lot of cases, you are doing that work for free. Not intentionally. But it’s buried in a flat rate that made sense when the contract was written, and nobody has updated the scope since.

    The fix is not complicated. But it does require a pricing conversation most MSPs have been avoiding.

    Why Bundling Security Kills Margin and Visibility

    When security work lives inside your managed services agreement, two things happen. First, the work is invisible — to you, to your clients, and to any prospect evaluating your practice. You can’t show a client what their security posture cost to maintain, and you can’t easily justify a rate increase when the scope expands because “security” was always included. Second, the margin on that work compresses silently over time. Security work is not static. Compliance requirements get stricter. Scan findings generate remediation work. Clients ask for audit-ready evidence packages. Each of those requests costs you time, and none of it is separately billable under a bundled agreement.

    The other problem is strategic. Bundling security means you have no clean mechanism to offer a better client a better service. You can’t tier your compliance coverage without renegotiating the entire MSA. You can’t upsell a client from basic vulnerability scanning to dark web monitoring to active directory security assessment if all of it is theoretically “included.” The pricing structure prevents the practice from growing.

    None of this is about squeezing clients. It is about making the work visible, protecting the margin on work you are already delivering, and creating the room to grow the practice without rebuilding contracts from scratch every time a client’s compliance needs change.

    Bundled Security vs. Separate Security Line Item

    ComparisonBundled SecuritySeparate Security Line Item
    Client visibilityInvisible — absorbed into flat rateClear deliverable with defined scope
    Your marginCompresses as scope creepsProtected by defined tier and pricing
    Upsell pathRequires MSA renegotiationTier upgrade is a straightforward conversation
    Compliance evidenceAd hoc, often undocumentedStructured, audit-ready by default
    Contract renewal leverageLow — security is “included”High — client can see what they’re getting
    Pricing modelPer seat, flat, or time-and-materials hybridPer user, predictable, scales cleanly
    Practice scalabilityLimited by bundled rate ceilingGrows by adding clients and upgrading tiers

    What a Separate Security Pricing Model Actually Looks Like

    The mechanics of separating security into its own line item are not complicated. The harder part is deciding what to charge and how to anchor the client conversation.

    Here is an illustrative example — not universal advice, since your costs, market, and client mix will vary — using a 60-user client, which is roughly average for MSPs operating in the compliance-focused SMB segment.

    If you are building on a white-label platform that costs you $6/user/month at the entry tier, your platform cost for a 60-user client is $360/month. A 100% markup puts your billing rate at $720/month. A 150% markup puts it at $900/month. That is the range on a basic vulnerability scanning and compliance monitoring service for a single mid-market client, billed as a separate security line item.

    At the mid-tier — $12/user/month platform cost — your cost for that same 60-user client is $720/month. With a 100% markup, you are billing $1,440. With a 150% markup, $1,800. For a client under active HIPAA or CMMC pressure, that is an entirely defensible number for what amounts to weekly active directory security assessments, multi-source sensitive data discovery, and compliance-mapped findings your client can hand to an auditor.

    At the premium tier — $18/user/month platform cost — cost is $1,080/month for 60 users. Markup to $2,160–$2,700. At this level you are delivering daily audit artifact generation, daily AD security assessment, AD password auditing, and daily attack path analysis. For a client carrying Level 2 CMMC requirements or a complex HIPAA environment, that is not an expensive security practice. It is a cost-effective alternative to what a dedicated security firm would charge for the same coverage.

    The key point in each scenario is that you are starting from a known, predictable platform cost and applying a consistent markup — not guessing at a time-and-materials number or trying to estimate hours on work that is ongoing and hard to scope precisely. Per-user pricing gives you a clean formula. The billable rate moves with your client’s headcount, not with how many devices they happen to have plugged in at a given moment.

    → The SentinelBaseline Platform page walks through all three end-client service tiers — Baseline, Baseline+, and Supreme — including what’s included at each level and how compliance framework coverage maps across them.

    Why Per-User Pricing Is Easier to Defend Than Per-Device in Regulated Environments

    Per-device pricing made sense when the asset inventory was stable — a known set of workstations, servers, and printers behind a defined perimeter. That model is increasingly unreliable for MSPs serving regulated clients, and the reasons are practical, not theoretical.

    Regulated SMBs are BYOD-heavy. Healthcare practices allow clinical staff to access EHR systems from personal devices. Defense subcontractors have remote employees using home laptops for CUI-adjacent work. Financial advisors are accessing client data from iPads. In any of these environments, a per-device pricing model fluctuates constantly, and the fluctuations generate billing conversations nobody wants to have. More devices means a higher bill with no obvious change in the service being delivered. Fewer devices — because a contract worker left or a laptop was decommissioned — means a lower bill that doesn’t reflect the same underlying compliance exposure.

    Per-user pricing ties your billing to the actual driver of compliance risk: the people in the organization with access to regulated data. The user count is stable, auditable, and easy for a client to verify. When a client under CMMC asks their assessor why their security bill changed, “we added three users” is a cleaner answer than “we added two laptops and lost one desktop and the BYOD count shifted.” The pricing logic also maps naturally to how compliance frameworks think about scope — CMMC Level 2 controls, HIPAA access controls, and PCI DSS requirements are all fundamentally about who has access to what, not about how many endpoints exist at a given moment.

    When to Position Baseline, Baseline+, and Supreme

    The three end-client service tiers are not a good-better-best upsell ladder in the traditional sense. They map to different compliance exposures and different risk profiles. Positioning them correctly means matching the tier to where the client actually sits — not selling the highest tier to everyone.

    Baseline at $6/user/month

    The right starting point for a client who has a compliance obligation — cyber insurance, HIPAA, PCI DSS — but has never had a structured security assessment before. The deliverable is Nessus-powered vulnerability scanning, compliance framework mapping across one framework, cloud and identity review, and sensitive data discovery from one cloud source. For a client who currently has nothing, this is a significant step up. It gives you a structured deliverable to bill for, and it gives the client something they can show an auditor.

    Baseline+ at $12/user/month

    For clients with active, recurring compliance requirements — CMMC Level 1 contractors with near-term SPRS obligations, HIPAA-covered entities running quarterly reviews, or any client whose insurance carrier is asking harder questions at renewal. The additions at this tier — weekly active directory security assessment, two-source sensitive data discovery, compliance mapping across three frameworks — are the features that generate the audit-ready deliverables a serious compliance review actually requires. This is where most growth-focused partners will land their primary client base.

    Supreme at $18/user/month

    For clients who cannot afford a security event — defense contractors handling CUI, healthcare organizations with large patient data footprints, financial firms under active regulatory scrutiny. Daily audit artifact generation, daily AD security assessment, AD password auditing, daily multi-step attack path analysis, and three-source sensitive data discovery. This tier positions your MSP as the client’s de facto security operations function, not just a scanning vendor. It is not for every client. But for the right client, it is the most defensible annual contract you will sign.

    The practical implication for pricing conversations is that tier selection should start with a compliance question, not a budget question. Ask the client what their compliance obligations are, what their assessor or insurance carrier is asking for, and what evidence they currently have to answer those questions. The tier positions itself from the answer.

    → The Partner Program page covers how partners can layer penetration testing on top of any end-client tier as a separate buying motion — a natural next step once the recurring scanning practice is in place.

    If you want to see what the pricing math looks like for your specific book of business — your actual client count, your target markup, your compliance mix — book a 30-minute demo. We will model the revenue for you during the call, show you the platform, and answer questions on onboarding and partner economics. No pressure. Just the numbers.

    → Book a Demo

    Frequently Asked Questions

    How do I have the pricing conversation with a client who currently has security bundled in their agreement?

    Start with what changed, not with pricing. If a client’s compliance requirements have tightened — CMMC Phase 1 is in effect, their insurer updated their questionnaire, PCI DSS 4.0 is now enforceable — that is the opening. “Your compliance exposure has changed, and what we were doing informally is no longer sufficient to meet the standard. Here is what a structured security practice looks like and what it costs.” The conversation is easier when it is anchored to a specific external requirement than when it is framed as you raising your rates.

    What markup should I use on security platform costs?

    That depends on your market, your cost structure, and what your clients will support — so this is not something to answer universally. The 100–150% range is a common starting point for MSPs entering the security practice space, because it leaves room to cover your operational overhead (onboarding time, client reporting, remediation oversight) while keeping the client-facing price defensible. As you add clients and streamline delivery, your effective margin improves without changing the billing rate.

    Does per-user pricing work if my clients have high contractor or seasonal workforce turnover?

    Generally yes, because the billing follows the current authorized user count rather than a fixed device inventory. If a client’s headcount fluctuates seasonally, you can set billing to reflect the current active user count. The bigger advantage is transparency — the client can verify their own user count easily, which makes the bill easy to explain and hard to dispute.

    Can I offer different tiers to different clients under the same partner agreement?

    Yes. Partners have access to all three end-client service tiers (Baseline, Baseline+, and Supreme). You are not locked into offering a single tier to your entire book. A client with a basic cyber insurance requirement might stay at Baseline while a defense contractor client moves to Supreme. Managing that mix is exactly what the platform’s multi-client structure is designed to support.

    How do I handle compliance framework selection with clients who don’t know what they need?

    That is a discovery conversation worth having deliberately rather than defaulting to whatever the client mentions first. Start with the question: “Who is asking you to prove security compliance?” The answer usually tells you the framework. Insurance carrier points to NIST CSF or CIS. A DoD prime contractor points to CMMC. Healthcare covered entity points to HIPAA. Payment processor or card brand points to PCI DSS. If a client has multiple overlapping obligations — a defense contractor who also takes payments — that is the argument for Baseline+ or Supreme, which map to multiple frameworks simultaneously.

    What happens to security pricing when a client’s compliance requirements escalate mid-contract?

    This is where a tiered per-user model is cleaner than a bundled agreement. When a client moves from Level 1 to Level 2 CMMC readiness requirements, or when their insurer asks for annual penetration testing in addition to scanning, the pricing conversation is a tier upgrade or an add-on — not a full contract renegotiation. The structure makes the upgrade conversation straightforward because both parties already understand what the current tier includes and what the next tier adds. See how Sentinel’s pricing model compares to typical competitor platforms.

  • How to Build an MSP Security Practice Without Adding Headcount

    If you run an MSP serving regulated industries — healthcare, government contractors, finance, professional services — your clients are asking harder questions about security than they were two years ago. CMMC 2.0 Phase 1 enforcement started in November 2025. PCI DSS 4.0 is fully in effect. HIPAA enforcement activity has been increasing year over year. Your clients’ auditors, their insurance carriers, and in some cases their primes are asking for evidence — not assurances.

    The question most MSP owners are quietly sitting with: Do I need to hire a dedicated security person to answer these questions, or is there another way?

    The answer is no — you do not need to hire first. But you do need a plan, and you need to be honest about what you’re actually capable of delivering versus what you’re just promising. This article is about the gap between those two things, and how to close it without building a security department from scratch.

    What Most MSPs Get Wrong When They Try to Build Security In-House

    The instinct is understandable: a compliance-obligated client asks for a vulnerability assessment, or CMMC proof, or a security review. You say yes. You buy a scanner license, run a scan, export a PDF, and email it over. The client accepts it — once. Then they want it monthly. Then they want framework mapping. Then they want it for a dozen clients. Then they want audit-ready evidence packages.

    This is where most MSPs run into the same three problems:

    The first problem is tooling fragmentation. You end up with a vulnerability scanner here, a dark web monitoring tool there, a manual spreadsheet for compliance tracking, and a separate report template that someone on your team updates by hand. None of it talks to each other, none of it scales, and the moment you add a second or third client with compliance requirements, the operational overhead starts eating margin.

    The second problem is proof quality. Running a scan and sending a PDF is not the same as delivering audit-ready compliance evidence. Regulated clients under CMMC Level 2, HIPAA, or PCI DSS need findings mapped to specific controls, evidence packages structured for assessors, and documentation that holds up under scrutiny. Generic scanner output rarely does.

    The third problem is who owns remediation. This is the one that actually costs you money. If your platform auto-prioritizes vulnerabilities but the remediation work gets done by someone outside your team, you lose the billable hours. That’s the business model risk that MSP owners rarely think about until it’s already happening.

    What Not to Build First

    Before you spend money on tools or time on process design, be clear on what you should not try to build in the first 90 days.

    Do not build your own compliance reporting infrastructure. This means do not try to hand-map findings to CMMC practices, NIST controls, or HIPAA safeguards using spreadsheets or homegrown templates. That work takes months to do correctly, requires ongoing maintenance as frameworks update, and is the exact kind of infrastructure that gets commoditized by purpose-built platforms. You are paying with your own time to do something someone has already solved.

    Do not hire a security analyst before you have a repeatable service. Bringing on a dedicated security person before you have clients paying for a security SKU is a cash flow decision, not a strategy. Validate the revenue first. The hire follows the proof point.

    Do not position yourself as a full-service MSSP on day one. You can grow into that. What you need on day one is a defensible, deliverable security assessment service you can actually fulfill without manual heroics. Start there.

    The Build-It-Yourself vs. Platform-Partner Decision

    Every MSP that seriously evaluates adding a security practice eventually faces this fork: build the capability internally using a stack you assemble yourself, or partner with a platform that productizes the infrastructure you need.

    Neither option is wrong. But they have very different economics.

    Building internally means licensing enterprise-grade scanning tools (Nessus Professional requires dedicated management and meaningful annual cost), building compliance mapping logic for each framework you want to support, creating client-facing deliverables from scratch, standing up a portal for client access, and maintaining all of it. For an MSP with 50–80 clients and a mixed book of business, the upfront investment and ongoing overhead is difficult to justify — especially when you’re not yet sure how many clients will actually buy the security tier.

    Partnering with a white-label platform means you’re trading capital and build time for a recurring per-user cost. The platform provides the scanning engine, compliance framework mapping, audit-ready reporting, and client portal — all under your brand. You provide the client relationship, the remediation delivery, and the oversight. The billable remediation hours stay in your business. The infrastructure cost is predictable.

    The right answer depends on your book of business and your risk tolerance. If you have 200+ clients and a compliance-heavy vertical specialization, building becomes more defensible over time. If you’re at 50–150 clients and you’re trying to prove the model before you invest heavily, a platform partner lets you get to revenue faster with less downside risk.

    One honest caveat on the platform path: not all white-label security platforms are built the same way. The critical questions are whether the platform keeps the end-client relationship 100% with you (no direct-to-SMB sales motion from the vendor), whether the compliance coverage is actually operationally mapped or just framework-badged, and whether the pricing model is predictable. Per-device pricing fluctuates as clients add BYOD assets and cloud infrastructure — per-user pricing does not.

    → See how the Sentinel Partner Program is structured, including tier pricing and what onboarding actually looks like.

    What a Lean MSP Security Practice Actually Looks Like

    A working MSP security practice at the 30–50 client scale doesn’t require a security department. It requires three things: a deliverable, a workflow, and a pricing model.

    The deliverable is a recurring security assessment — vulnerability scanning, compliance framework mapping, dark web and credential monitoring, and a monthly or quarterly report your client can share with their auditor, their insurance carrier, or their compliance officer. The report carries your brand. The findings are specific and actionable. The evidence is structured.

    The workflow is what keeps this from becoming manually intensive. Scans run on a schedule. Findings are prioritized automatically. Reports are generated without someone on your team spending three days per client building a document. Remediation tickets flow into your PSA so the work gets assigned, tracked, and billed. This only works if the platform integrates with your existing stack — ConnectWise, Datto, HaloPSA, whatever you’re running.

    The pricing model is where most MSPs leave money on the table. Security services should not be buried inside your managed services contract. They should be a separate line item, with a defined scope, billed per user or per client per month. That separation is what makes the practice visible, protects your margin, and creates a clean upsell path for penetration testing and compliance readiness when clients ask for more.

    90-Day Launch Checklist for an MSP Security Practice

    This isn’t a roadmap for building a security department. It’s a minimum viable checklist for getting a billable security service in front of clients within a quarter.

    Weeks 1–2: Foundation

    • Define your ideal client profile for security services (industries, compliance frameworks, revenue threshold)
    • Select your platform or tooling approach and complete vendor evaluation
    • Identify 2–3 existing clients who have asked about security, compliance, or vulnerability scanning
    • Sign your platform agreement and begin onboarding

    Weeks 3–4: Technical Setup

    • Deploy scanning agents across your first pilot client environment
    • Connect your PSA integration (ConnectWise, Datto, HaloPSA)
    • Set up your white-label portal and client-facing report branding
    • Select the compliance framework(s) most relevant to your first client (CMMC, HIPAA, PCI DSS, NIST CSF)

    Weeks 5–6: First Deliverable

    • Run your first scan on a pilot client and complete a findings review
    • Build your first monthly summary report and review it internally before client delivery
    • Identify the top 5 remediation items and create PSA tickets — bill for remediation time
    • Deliver the report to your pilot client and walk through findings with them

    Weeks 7–10: Pricing and Packaging

    • Finalize your security service tiers and per-user or per-client pricing
    • Document your security practice scope of work (what’s included, what triggers a separate engagement)
    • Create a short one-page overview of the service for existing client conversations
    • Identify your next 5 clients for rollout based on compliance exposure

    Weeks 11–12: Revenue Activation

    • Amend agreements or send addendums converting pilot clients to a paid security tier
    • Begin outreach to your next client cohort
    • Schedule your first quarterly business review with a security focus for at least one client
    • Document what worked, what broke, and what you’d change for the next cohort

    What Happens After Day 90

    The first 90 days are about proof, not scale. You’re proving to yourself that the workflow is sustainable, that clients value the deliverable, and that the pricing model holds. Once that’s true, the practice scales by adding clients, not by adding headcount.

    The inflection point most MSPs hit around the 10–20 client mark on a security SKU is the conversation about penetration testing. Recurring scanning and compliance monitoring answer the “what’s exposed” question. Penetration testing answers the “can it actually be exploited” question. For clients under CMMC Level 2 or heading into a SOC 2 audit, that’s a natural expansion of scope — and a significant revenue opportunity that doesn’t require you to employ a red team.

    The other inflection point is the contract transition conversation. A meaningful portion of the MSPs who want to add a security practice are already under multi-year agreements with existing security vendors. That’s not a reason to delay evaluation — it’s a reason to understand what your transition options look like before you need them urgently.

    → See how Sentinel compares to typical competitor platforms across CMMC depth, pricing model, and partner support.

    Southern Sentinel is a channel-exclusive managed security platform — we do not sell to end-clients, and we do not compete with our partners. If you want to see how the platform fits your specific book of business, book a 30-minute demo. We’ll walk through the scanning workflow, model the revenue for your client count, and answer questions on onboarding, compliance mapping, and partner economics.

    → Book a Demo

    Frequently Asked Questions

    How many clients do I need before it makes sense to build an MSP security practice?

    There’s no universal threshold, but most MSPs find the model starts working at 10+ clients who have active compliance requirements — whether that’s HIPAA, PCI DSS, CMMC, or cyber insurance mandates. If you have 50+ clients and at least 20% of them have compliance exposure, the economics of a dedicated security practice are very defensible. Below that, the question is really about whether you want to specialize the practice or serve it opportunistically.

    Do I need to hire a security analyst to deliver compliance-grade security services?

    No — not on day one. What you need is a platform that does the heavy lifting on scanning, framework mapping, and report generation, and a team member who can own the client conversation and remediation oversight. That’s often a vCISO role, an account manager with security training, or in the early days, the owner or practice lead. The analyst hire makes sense once the practice revenue justifies it, not before.

    What’s the difference between white-label security for MSPs and just reselling a scanner?

    Reselling a scanner gives you a tool. A white-label security platform gives you a service you can deliver under your brand — with client-facing portals, compliance-mapped reporting, PSA-connected remediation workflows, and audit-ready evidence packages. The scanner is an input. The platform is the entire production system. The distinction matters when your client asks you to produce compliance evidence, not just a scan report.

    What compliance frameworks should I prioritize when launching a security practice?

    Start with whatever your existing clients are actually obligated to. If you serve healthcare, HIPAA is the entry point. If you have defense contractor clients, CMMC is the priority — Phase 1 is in effect and Phase 2 mandatory C3PAO certification starts November 2026, so the urgency is real. If you serve financial services or retail, PCI DSS 4.0 is the anchor. Don’t try to cover every framework on day one. Cover the one that’s creating the most client pressure.

    Can I add penetration testing to my security practice without building a red team?

    Yes — and for most MSPs, that’s the right model. Recurring vulnerability scanning and compliance monitoring is a separate motion from penetration testing. Pen testing is a periodic, scoped engagement that answers a different question. The most practical path is to offer pen testing as an add-on through a white-label partner or subcontracted service, rather than building internal offensive security capability from scratch.

    What should I do if I’m locked into a contract with an existing security vendor?

    Evaluate your options before assuming you’re stuck. Some platforms offer contract transition programs that let you run both platforms simultaneously at no charge during your remaining vendor term, so you can prove the new model without paying double. If that option exists with your prospective partner, the question becomes whether the evaluation period is long enough to complete a fair comparison — not whether you can switch at all. See how Sentinel’s contract transition program works.