Does SCOUTz require prospect consent before running a domain scan?

Consent requirements depend on what a SCOUTz domain scan does: public-domain observation must be distinguished from active probing, and Microsoft 365 reviews require customer authorization. For prospect outreach, offer a scoped review as an opt-in courtesy after a reply. A publicly reachable domain does not establish permission for every assessment technique or access to internal tenant evidence.

Why this matters

The word scan hides important differences. Reading published domain information, actively testing a service, and reviewing a Microsoft 365 tenant involve different sources, boundaries, and authorization decisions.

SCOUTz cybersecurity prospect intelligence is best for MSPs preparing sales conversations with dated evidence and explicit assessment limits. The SCOUTz approach keeps the relationship and the sale with the MSP. Your responsibility includes deciding what work is appropriate before turning a prospect's domain into an assessment target.

Use the distinction below in your 2026 prospecting procedure. Keep the outreach decision separate from the technical capability to run a review.

Does SCOUTz require prospect consent before running a domain scan?

Customer authorization is required for Microsoft 365 review; public-domain review needs a separate scope and permission decision. Neither the phrase public domain nor the availability of a scan establishes blanket legal clearance for unsolicited assessment activity.

The client's October 15, 2026 editorial standard separates public observations from consented internal evidence. It also directs MSPs to offer outreach scans as opt-in courtesies after a reply. Apply that distinction before selecting a review.

These are different activities, not interchangeable assessment tiers. Public observation supports a narrower conversation. Authorized tenant evidence supports a different one, with additional permission and coverage boundaries.

For the broader permission question, see whether MSPs can scan a prospect's domain before getting permission. Treat legal research as a starting point for review, rather than approval to run every available technique.

Public-domain review: useful evidence, limited conclusions

Public-domain review helps you prepare questions about published domain and email-security conditions. Its strength is the ability to attach a visible condition to a source and run date. Its limitation is equally important: an external observation cannot describe everything happening inside the organization.

For example, a published DMARC policy requesting monitoring supports a conversation about intended enforcement and reporting. It does not establish that someone compromised an account, that the organization ignores reports, or that a change remains outstanding.

Keep the observation and interpretation separate:

• Record the condition: the published policy requests monitoring.
• Attach the evidence: retain the check name, affected domain, source, and actual run date.
• State the boundary: the policy does not establish compromise or the organization's intended change schedule.
• Identify the owner: ask who owns domain policy and reviews reports.
• Offer the next choice: agree whether to investigate, defer, or leave the intended policy unchanged.

A finding becomes useful sales preparation when it supports a question the prospect can answer. Turning the same finding into an accusation removes that boundary.

Public Domain Review also cannot establish Conditional Access coverage, application permissions, license assignments, Intune device state, or tenant sharing configuration. Mark those areas outside the assessment rather than filling them with assumptions.

Microsoft 365 review: customer-authorized, read-only evidence

A Microsoft 365 review uses customer-authorized access to configuration and metadata. The stated boundary excludes mail, files, chats, documents, and prompts. Read-only review makes no automatic configuration changes and requires no agent or install.

That boundary is useful, but it does not replace authorization. The prospect still needs to understand what the review will access, which tenant is in scope, who approves it, and what evidence the MSP intends to discuss.

Coverage needs its own explanation. Permission-limited or license-limited evidence remains limited even when the review completes. A completed run is not proof that every relevant source was assessed.

Keep evidence states distinct: Verified, Observed, Inferred, Possible, Unknown, and Unreadable. Keep coverage distinct too: Assessed, Partial, Not assessed, Permission limited, and License limited.

Unread evidence stays unknown. Put declared non-reads under NOT ASSESSED THIS SCAN. That statement gives the prospect a usable boundary and prevents a report from implying clean results where nothing was read.

Why consent requirements vary by review scope

The consent question changes with the work you propose. Review these factors before scheduling activity or promising a report:

• Evidence source. Published domain information and consented tenant configuration are separate sources with different boundaries.
• Collection method. Public observation and active probing require separate evaluation; calling both a domain scan obscures the distinction.
• Authorized scope. Record the domain or tenant, intended review, permitted access, and exclusions before proceeding.
• Applicable legal context. The client's scanning-law research is preliminary educational material, not completed nationwide clearance or legal advice.
• Evidence access. Permissions and licensing affect what a tenant review can read and what the report must leave unknown.
• Outreach method. A prospect's reply, an assessment authorization, and permission to send a report are separate decisions to document.

For your 2026 operating procedure, make these fields part of the handoff between sales and the practitioner responsible for the review. Sales should be able to explain the proposed scope before technical work starts.

Move from permission to an agreed next action

The SCOUTz Evidence-to-Agreement Framework gives MSPs a way to connect a scoped review to a buyer-owned decision: Find the decision, Bring the evidence, Build the scope, Earn the next commitment. It is an original conversation framework, not a validated close-rate intervention.

Use the sequence after a prospect agrees to discuss a review. Keep permission visible throughout; an initial reply does not authorize every later activity.

Find decision

Identify the decision the prospect wants help making. That might be clarifying responsibility for an email-security policy or deciding whether an authorized tenant review is appropriate.

Write down the decision in business terms. Avoid starting with a proposed vendor change before the relevant condition and ownership are understood.

Bring evidence

Present the observed condition with its check, source, and run date. Explain what the evidence supports and what remains unknown.

For a monitoring-only DMARC observation, discuss intended policy and report ownership. Leave compromise, remediation status, and buying intent out of the claim unless separate evidence establishes them.

Build scope

Separate the affected object, unknowns, and recommended outcome from the vendor choice. The MSP and prospect can then decide whether the next step is a service, process change, project, further review, or no action.

An external domain observation does not silently expand into permission to inspect a tenant. Obtain authorization when the proposed evidence source changes.

Earn commitment

Agree on a specific next action, its owner, and the evidence needed to complete it. Examples include confirming policy intent with the current administrator or authorizing a read-only tenant review.

The commitment belongs to the prospect. A useful meeting can end with a documented decision to defer.

This workflow gives the MSP a concrete destination beyond presenting findings. The output is an agreed action and scope, rather than a report delivered without context.

Keep the outreach invitation smaller than the assessment

Offer the review after a reply, with a clear purpose and boundary. The invitation should explain the proposed activity without suggesting that the prospect already has a confirmed security incident.

Illustrative outreach wording:

With your permission, we can review the agreed domain and discuss the dated observations with whoever owns email security. We will identify what the review assessed and what it left unknown. Any Microsoft 365 review would require separate customer authorization.

This wording offers a choice. It does not present an unread environment as assessed or imply that accepting a conversation commits the prospect to remediation.

If the prospect says the existing provider handles security, acknowledge that ownership. Suggest including that provider in the discussion or asking the prospect to confirm the intended policy internally. Evidence can clarify responsibility without manufacturing conflict.

For 2026 outreach, retain appropriate sender identity and opt-out handling for report emails. Treat an email open as a follow-up cue; agreement requires an actual response with sufficient scope.

What should I record before running the review?

Record the prospect's agreed scope, the approving party, the domain or tenant, and the review's purpose. Preserve the authorization alongside the account context so the practitioner can see what sales actually agreed.

Keep the evidence record equally specific: source, date, confidence, expiry, observation, implication, questions, and safe offer. Use the actual run date. A 2026 article or proposal date does not make an older observation current.

Does read-only access remove the need for authorization?

Read-only access does not remove the need for customer authorization. It describes an access boundary, while authorization establishes whether the review is permitted within the agreed scope.

Explain both. A prospect should understand the evidence source and the limits of the work before approving it.

Can a public-domain finding justify a proposal?

A public-domain finding can support a scoped proposal when the prospect agrees on the condition, owner, and desired outcome. The finding alone does not establish that the issue remains unresolved or that the prospect wants to buy.

Build the proposal around the agreed decision. If the requested outcome requires internal evidence, make authorized assessment part of the scope before claiming a solution is needed.

FAQ

One last thing

Permission to review and permission to claim are different. Even after an authorized assessment, every statement still needs evidence, a date, and a boundary. Proof comes from a rescan against a pinned baseline, with comparable coverage and the remaining unknowns visible.

For MSPs evaluating this approach, Join Open Beta is the primary next step. Keep the first conversation focused on your evidence workflow and assessment boundaries; responsibility for the relationship and sale stays with you.

Related guides

• Security assessments without access to a client's network
• Sending unsolicited security reports as an MSP
• From domain scan to first-call evidence packet