Scanning Without Asking: The Boundary for Read-Only Assessment.

There's an uncomfortable fact at the front door of this whole business, and I'd rather address it head-on than hope nobody notices. The read-only domain review runs without the target's consent. An MSP types in a prospect's domain, and minutes later there's a report about a company that never agreed to be looked at. If that doesn't give you at least a moment of pause, it should, because it gave us more than a moment when we designed it.

So let's talk about where the line actually is, and why we built ours well inside it.

The line, across basically every legal framework that touches this space, comes down to one concept: authorization. Reading information that an organization has published to the public internet—its DNS records, certificates, and services deliberately made visible to the world—is observation of public information. It is the digital equivalent of reading the signage on a building from a public sidewalk. Accessing a private system, logging in, testing credentials, or testing a weakness is a different act. The read-only domain review is designed to stay inside the first category. I'm not your lawyer and this isn't legal advice, but I can tell you the principle we built to: if it isn't published, we don't read it.

Privacy law adds a second boundary, and we took it just as seriously. Modern privacy regimes, the GDPR being the loudest but far from the only one, are concerned with data about people. So we made the domain review a tool that examines organizations, not humans. It doesn't harvest employee email addresses. It doesn't scrape personal profiles or build contact dossiers. It doesn't parade breached credentials across a screen for shock value. The subject of the report is a company's public technical posture, and the humans who work there are, by design, not in it. Plenty of tools in this market made the opposite choice, because people-data makes for spicier reports. We think it makes for legal exposure wearing a costume.

Which brings me to the reason all of this matters more for us than for most vendors: our partners' names are on these reports. SCOUTz is channel-only. When a scan gets run, it's run by an MSP, under their brand, and handed to a prospect as their work. That's a responsibility structure most scanning vendors never have to think about, and it changed how we drew every line. A vendor selling direct can decide to operate in gray areas and eat their own risk. We don't have that option, because the risk wouldn't be ours to eat. It would land on a 12-person MSP in Ohio who trusted our engineering, and no feature is worth that.

So the partner-protection decisions stack up the same way every time. No active probing capability exists in the product, so a partner cannot accidentally probe. No personal data collection exists, so a partner cannot accidentally build an unlawful dossier. The methodology is written down in plain language, so when a prospect's attorney asks how this report was produced, and the good prospects will ask, the partner hands over a document instead of a shrug. We didn't just decide to behave well. We removed our partners' ability to behave badly through us, which is the only version of responsibility that survives scale.

The reframe is simple: operating inside the lines isn't a constraint on the sales motion. It is the sales motion. You're walking into a first meeting demonstrating knowledge of a company that never invited you. The only way that lands as impressive rather than invasive is if you can explain, calmly and completely, exactly how you know what you know and why every bit of it was public. The vendor who can survive the lawyer's questions gets the second meeting. The one who can't was never really prepared, no matter what their report said.

Scan without asking, sure. But earn the right to, in the design, before the first domain ever gets typed in. That's the standard we held ourselves to, because our partners are the ones holding the report.