Discovery starts with a clear deployment boundary

A discovery evaluation starts before the first scan. The useful questions are practical: which source will be connected, what may the scanner read, and where will processing take place?

Define the source and the scope

A database, an object store, and a document collection have different access patterns. Agree on a representative source and a limited scope that your team understands. Record the tables, paths, or objects included in the evaluation, as well as those excluded.

Connector availability and behavior should be checked for the specific system and version you want to use. A connector name alone does not describe its operational requirements.

Understand processing and persistence

Deployment labels such as “on-premise” or “agentless” do not answer every data-handling question. Discuss the complete path: source access, worker processing, findings storage, logs, and any external services involved.

Read-only access can still create load. An evaluation should include the query pattern, scan scheduling, concurrency, and source-side monitoring appropriate to that environment. Avoid treating read-only as a guarantee of zero performance impact.

Agree what success looks like

For an initial Pelestra discussion, bring a concrete source and a question your team wants to answer. For example: where do personal identifiers appear in an onboarding dataset, and what context does a reviewer need to assess the findings?

A useful evaluation ends with a understood scope, findings your team can inspect, and deployment boundaries you have checked together. Those are stronger foundations than a universal claim about speed, accuracy, or data movement.