–
Category: MSP Resources
-
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 Revenue Engine model that runs the fastest close cycle — from ad click to verbal agreement in under 24 hours, signed MRR in under 48 hours — works because the evidence does the selling before the prospect ever talks to a person. They have already seen the scan results, already completed the self-assessment, already received the branded report with their name on it. By the time they get on a call, the decision to engage is already 80% made. The call is confirmation, not conversion.
→ The 48-Hour Security Revenue Engine walks through the full workflow — how evidence-led outreach, free tools, and a structured follow-up sequence combine to move a cold prospect to a signed agreement in under two business days.
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.
→ The lead magnets page has all of these resources, including the SMB Cybersecurity Checklist, CMMC 2.0 Readiness Guide, Cost of a Breach Calculator, QBR Security Slide Deck, Cold Email Sequences, and Objection Handling Playbook.
If you want to see how the free tools, self-assessment workflow, and Revenue Engine fit together as a complete go-to-market system — and how the platform’s compliance mapping supports the evidence-led conversations this article describes — book a 30-minute demo. We will walk through the full workflow with your specific client segments in mind.
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
Vulnerability Scanning Penetration Testing Primary goal Identify and track known weaknesses across the attack surface Determine what an attacker can actually do by exploiting those weaknesses How it works Automated tool checks systems against a vulnerability database Qualified human tester attempts to exploit vulnerabilities using real attack techniques Cadence Continuous — monthly, weekly, or daily depending on tier Periodic — typically annual, or event-driven (before an audit, after a major change) Depth Broad coverage across all discovered assets; identifies potential vulnerabilities Narrow scope, deep exploitation — confirms which vulnerabilities are actually exploitable and to what consequence Human judgment required No — automated discovery and matching Yes — chaining vulnerabilities, escalating access, assessing real business impact Primary output Prioritized vulnerability list with remediation guidance, mapped to compliance frameworks Narrative report of attack path, what was accessed, and business impact of a real breach Compliance value Satisfies continuous monitoring requirements under CMMC, HIPAA, PCI DSS, NIST CSF, SOC 2 Often required separately for audits, insurance underwriting, or pre-certification assessments Cost model Predictable recurring — per user, per month Project-based — scoped per engagement When to recommend Every compliance-obligated client, always Clients 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 Growth and Flagship 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 Growth and Flagship partners, book a 30-minute demo. We will walk through both service motions with your specific client mix in mind.
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.
-
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.
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 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 sequence that produces the fastest close — the ad click to verbal agreement in under 24 hours that the Revenue Engine is designed around — works because the prospect has seen evidence before they ever talk to a person. The external findings, the self-assessment report, the compliance implication — by the time they are on a call, the decision to engage is already substantially made. The call is confirmation and scoping, not persuasion.
→ The 48-Hour Security Revenue Engine walks through the full workflow — how evidence-led outreach, free tools, and a structured follow-up sequence combine to move a cold prospect to signed MRR in under two business days.
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 the full external check suite, self-assessment workflow, and Revenue Engine fit together as a system — and how the platform’s OSINT and external scanning integrates with ongoing client security monitoring — book a 30-minute 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.