PUBLIC
Company, Domain, DNS, email, web. No credentials or agent.
TRUST
Credibility starts with a boundary the MSP can explain.
SCOUTz is designed to disclose consent, source, timestamp, coverage, inference, and limitation before a conclusion reaches a seller or client.
PASSIVE → CONSENT → READ-ONLY
Start with observation. Go deeper with permission.
Permission should follow purpose. The source required to answer the question determines the appropriate access boundary.
CONVERSATION
Explain the observation, unknown, purpose, and limit.
CONSENT
The customer authorizes a defined deeper source.
READ-ONLY CLOUD
Identity, applications, OAuth, licensing, sharing, managed devices, and AI context where supported.
DEEPER EVIDENCE
Stronger source, still bounded by permission, license, provider, and readability.
AUTHORIZED APPLICATION EVIDENCEcan support permissions, owners, consent, assignment, and available activity≠EMPLOYEE CONTENT
Minimum access
Domain review uses public information. Microsoft 365 review requires customer approval and read-only collectors.
No content reads
No message bodies, documents, files, chats, or prompts are part of the current review design.
No automatic changes
SCOUTz guides investigation and remediation. The MSP validates, approves, performs, and owns the work.
Provenance retained
Source type, URL or collector, timestamp, entity-match confidence, and signal age travel with the evidence where applicable.
Coverage disclosed
Permission, license, source, and readability limits are shown instead of silently scored as safe.
Audience separated
Client-safe reports stay distinct from operator evidence, sales hypotheses, external intelligence, and workbooks.
PRIVACY BY DESIGN
Privacy starts with what we choose not to collect.
SCOUTz asks for evidence proportionate to the question. Public discovery stays within its disclosed purpose. Deeper cloud evidence requires customer authorization. Configuration and metadata are preferred over content.
Good review does not mean maximum access.
Question → necessary evidence → appropriate access. Read-only limits what the platform can change. Data minimization limits what it should collect. Both boundaries matter.
Read why privacy begins in the architecture →SCOUTz capabilityDefined purposeAccess model
Prospect IntelligencePrepare a legitimate business conversationPublic and approved sources
Domain ReviewEvaluate public external postureBounded public observation
Cloud ReviewEvaluate supported internal cloud evidenceCustomer-authorized read-only access
Guided RemediationExplain and organize corrective workExisting evidence; MSP-owned change process
VerificationConfirm an observable condition changedAuthorized reassessment of the supported source
No legal theater. These design choices align with principles such as purpose limitation, data minimization, transparency, accuracy, storage limitation, and security. They are not a claim that SCOUTz is automatically compliant with every privacy law or jurisdiction.
THE WORDING FOLLOWS THE EVIDENCE
Identity exposure, with context.
SCOUTz treats an email association, reported password material, current credential validity, and current account compromise as separate evidence states. A narrower source does not silently become a stronger claim.
Observed evidenceNot automatically establishedResponsible use
Email identifier in historical breach dataCurrent corporate password exposurePreserve source, date, match, evidence type, freshness, and the limitation.
Password material reported by a sourceThat the material is current, valid, or tied to the corporate accountState whether the source describes plaintext, hash, partial, or unknown material.
No current validation sourceA clean account or an active compromiseMark current status unknown and turn the evidence into a discovery question.
Company-first does not mean people-data-first.
Public availability is not a reason to build a person-level dossier. Personal detail needs a defined purpose, access boundary, display rule, retention decision, and deletion or suppression path. The MSP should receive enough context to act responsibly—without using an employee as a sales prop.
Read the identity-exposure evidence standard →PROGRESSIVE PERMISSION
Deeper access should be earned by the conversation.
The prospect should understand what SCOUTz reads, why it is needed, what remains outside the boundary, and that the review does not make production changes.
PUBLIC
Company and domain evidence with no tenant access.
ASK
Explain the unknown and the source required to answer it.
AUTHORIZE
The customer approves the stated Microsoft review purpose.
READ-ONLY
Collect supported configuration and metadata, not content.
VERIFY
Return only where the approved source can show change.
No magic close-rate math. No guarantee hidden in smaller type.
SCOUTz cannot control the buyer, budget, timing, incumbent, competition, or final decision. It can help an MSP prepare with evidence, name the unknowns, ask better questions, and keep the next action connected to the reason it exists.
What we will—and will not—put in writing →DESIGNED
We will tell you what SCOUTz is designed to do.
SUPPORTED
We will tell you what the evidence supports.
UNKNOWN
We will tell you when the source cannot establish the answer.
PERMISSION
We will tell you what requires customer authorization.
NO GUARANTEE
We will not promise that software makes the prospect buy.
SCOUTz OPEN BETA
Point SCOUTz at the question. Walk in with a defensible answer.
Bring a real MSP workflow and see how SCOUTz turns evidence into the next defensible action. The review runs without an agent or install and never changes configuration automatically.
SCOUTz prepares the conversation. The relationship and the sale stay yours.