The External Surface Playbook for MSPs

Start with the account, not the tool

An external surface review is useful to an MSP when it answers one practical question: what can we responsibly show this prospect about its published environment before asking for deeper access? The SCOUTz playbook is simple. Define the account and purpose, review the public evidence, name what remains unknown, ask before sending the report, and let the prospect choose the next conversation.

This is not a license to mail unsolicited findings to every business in a local directory. The first service decision is whether the person on the other end invited the contact. The second is whether the evidence supports a useful question. The report is the middle of that exchange, not the reason to skip it.

Step 1: Choose one account and write the purpose

Start with a real account, not a list. Record the company name, domain, source of the account, why it fits the MSP, and the person who can decide whether a conversation is useful. Write the purpose in one sentence: “We want to understand whether the public mail and web configuration gives us a responsible question for the owner.”

That sentence keeps the review narrow. It also stops a seller from treating every observed detail as a sales opening. A public record is relevant only when it helps the MSP understand the account or prepare a question the account can answer.

Step 2: Check the boundary before you check the domain

SCOUTz starts with public evidence. The domain layer can read supported DNS, email-authentication records, certificates, headers, and related public signals without credentials or an agent. It cannot see internal identity, endpoints, backup recovery, private applications, or how the business operates day to day.

Say that boundary before the review is presented. A prospect should know that the result is a dated outside-in record, not a penetration test, a live monitoring service, or a statement that the business is compromised. If the prospect has not agreed to receive a report, do not send one. Offer the courtesy and wait for the reply.

Step 3: Run the public review and read the evidence page first

When the review is complete, start with the evidence page rather than the score or the most dramatic finding. Confirm the domain, run date, source label, and coverage state. Separate what was observed from what was inferred. A finding may say that a policy is published at a certain state. It should not silently become a claim about what an attacker will do next.

Look for one or two conditions that a business owner can understand and verify. Mail authentication, a certificate issue, an exposed login route, or a missing security contact can be relevant. A long inventory is not a better conversation. The first goal is a defensible reason to ask a question.

Step 4: Translate the condition into a business question

The report is written for a conversation, not for a scare slide. Convert each selected finding into four sentences:

• Here is what the public source shows.
• Here is the date and the limit of that observation.
• Here is the business process that could be affected.
• Here is the question the owner can answer.

For example, a monitor-only DMARC policy is a published condition. The useful question is who owns invoice and executive-mail impersonation risk, what the current provider has already reviewed, and whether the renewal process expects an enforcing policy. The answer may be “we have a compensating control.” That is useful too. The point is to create a truthful next question, not to force a predetermined conclusion.

Step 5: Send the invitation, not an attachment

The best first message is short. Identify the MSP and its specialty. Say that you noticed a public condition on the company's domain. Offer to send a dated, outside-in report that can be used with the existing IT provider. Make the booking link optional. Ask whether the owner would like to see it.

Nothing runs until the recipient says yes. The reply is the consent that changes a public observation into a useful exchange. If there is no reply, the MSP has still behaved like the partner it says it wants to be.

Step 6: Walk through one finding and one unknown

When the prospect accepts the report, lead with the finding they can check. Then show one unknown that the public layer cannot answer. This pairing prevents the report from pretending to be complete. It also makes the next layer obvious without turning the conversation into a product demo.

Ask who owns the condition, how it is handled today, and what evidence would settle the open question. If the answer requires customer-approved Microsoft 365 configuration or metadata, explain the source, permissions, and read-only limit before requesting access. A deeper review is earned by the question, not by a generic feature list.

Step 7: Let the prospect choose the next step

There are several responsible outcomes. The owner may ask the current provider to review the condition. They may want the MSP to scope a small project. They may authorize a deeper review. They may decide that the timing is wrong. Record the choice and the reason. A useful report can improve the conversation even when it does not produce a contract.

The MSP owns the relationship and the recommendation. SCOUTz keeps the source, date, unknowns, questions, and next choice attached so the work does not dissolve into a generic follow-up task.

The five-minute version

Before a meeting, an MSP should be able to answer five things: why this account, what the public source shows, what it cannot show, who owns the next question, and what choice the prospect can make now. If the seller cannot answer those five, the report is not ready to send.

Frequently asked questions

What is an external surface review?

It is a bounded view of what an organization publishes to the internet, such as DNS, email authentication, certificates, headers, and selected exposed signals. It is evidence from outside the environment, not a complete internal assessment.

Should an MSP send an external report before the prospect asks for it?

Offer the review first and send it after the prospect opts in. Consent protects the relationship and makes the report a useful conversation rather than an unsolicited claim.

What should an MSP do with the first finding?

Name the source and date, explain the business consequence without predicting compromise, ask who owns the condition, and offer one next choice that the owner can accept or decline.

What does a domain review not prove?

It does not prove internal identity controls, endpoint posture, recovery readiness, current compromise, or buying intent. Those questions need a different source or an explicit owner confirmation.

When should the MSP ask for a deeper review?

Ask when the prospect understands the public finding, agrees that the question matters, and can authorize the specific read-only source needed to answer it.

How SCOUTz gets you there

SCOUTz gives the MSP a dated public-domain record with source labels, coverage limits, business-language explanations, and explicit unknowns. The report is designed to be offered as a courtesy, accepted by the prospect, and used with the existing provider. When the question earns a deeper review, the same evidence thread can carry into customer-approved read-only cloud evidence and the next responsible decision. The open beta is free for thirty days at scoutzsecurity.io.