Skip to main content

Scan an estate

Scanning answers what is out there, and what is wrong with it, without taking custody of any of it. It is the basis of an assessment engagement, and the whole design turns on one promise:

Nothing moves. Every scan records the data-movement answer, and it is none.

Before you scan: authorize the scope​

A scan runs under an engagement, and the engagement's scope is signed.

That is not ceremony. For a regulated or government engagement the procurement question is not whether you found things, it is whether the scanner could have touched anything outside what was authorized. A signed scope answers that.

The scope is canonicalized before signing, so re-serializing it still verifies while any semantic change breaks the signature. Out-of-scope targets are denied at the boundary, and an engagement can only assess targets it names.

Where no signing key is provisioned, the system refuses to sign rather than producing a signature that proves nothing.

Choose the depth​

Depth is the main cost and risk control, and the default reads nothing.

DepthWhat it reads
Shallow (default)Catalog metadata only. No rows
StandardPer-column sample statistics
DeepFull profiling

Standard and deep need an explicit budget uplift. Start shallow: for most assessments the inventory and the governance findings are the deliverable, and neither needs a row.

Every scan is bounded three ways: scope (a finite set of catalogs, schemas and patterns), budget (objects, bytes, wall-clock, compute) and depth. Hitting a budget cap ends the scan as over-budget. It never retries or escalates.

Scan a data estate​

Point the engagement at a stored connection, not at a credential. The scan descriptor carries a reference; the secret is resolved inside the service that owns the data path and never comes back.

What gets read depends on the source:

  • Relational and warehouse: system catalogs only. No data manipulation, no schema changes, no temporary tables, no locks.
  • Object stores: listings with format detection, size, content type and modification time.
  • Access posture: principals, privileges and policy bindings. Metadata only, credential-free.

Scan a cloud account​

Cloud scanning reads a posture inventory: buckets and their access and encryption settings, network rules, identity policies. Not data.

Grant precisely what a scan needs. Every API call the enumerators make is mapped to the exact permission it requires, alongside the acceptable managed read-only role for each cloud, in scanning external platforms.

Sovereign partitions are fail-closed. An engagement at a given impact level refuses a lower-partition enumerator rather than falling back, and a provider with no equivalent partition refuses outright rather than substituting a commercial region. Record the approving authority before you start: the system requires it for the higher tiers.

Scan a virtualization estate​

vSphere needs the built-in read-only role on the inventory root, propagating. There is no provisioning path.

It reads virtual machines, hosts, datastores and networks, and evaluates eight hardening rules. Two caveats worth knowing before you promise anything: consolidation analysis needs performance counters the scan does not collect, and two rules default to the safe answer where the interface does not expose the value reliably.

Read the findings​

Findings land against the engagement, superseding the previous run rather than accumulating, so there is at most one live assessment.

The scorecard reports an overall health score across four dimensions, a control-gap grid against common frameworks, and a prioritised remediation roadmap.

One property to rely on: findings are conservative on thin inventory. Where age, ownership or hash data is absent, the rules depending on them do not fire rather than firing on a guess.

Produce the deliverable​

A report renders from one structured source into both readable and self-contained formats: the estate inventory by kind, the read-only guardrail audit, recommendations by severity, and the migration plan.

Approving it signs it, separately from the scope signature. The per-engagement hash chain proves integrity but is anonymous; approval signs the approved content into a manifest the client re-verifies independently. Integrity and attribution are different claims and get different mechanisms.

Diagrams export as editable or deterministic formats, and never invent data: an empty source yields an empty but valid document rather than a placeholder.

Verify it worked​

#CheckWhy this one
1The scan reached a terminal stateComplete, over-budget or error. A pending scan is the thing to chase
2The scope snapshot matches what you authorizedIt is immutable and recorded per scan
3The data-movement answer is nonePrinted on the deliverable, not just asserted here
4Findings superseded the previous runOne live assessment, not an accumulating pile
5The deliverable verifiesThe client can check the signature without you

When it does not work​

SymptomMost likely causeWhat to do
The scan is refused before it startsNo backend for that source kindDeliberate. A scan that cannot run is never created, so nothing sits pending behind a missing backend, and nothing reports a clean estate that was never looked at
A target is deniedIt is outside the engagement's authorized scopeThe scope is signed. Widen the engagement rather than the scan
A sovereign engagement refuses a cloudNo equivalent partition for that providerFail-closed by design. It will not substitute a commercial region
The scan ends over budgetA cap was reachedIt does not retry or escalate. Narrow the scope or raise the budget deliberately
Findings are thinner than expectedShallow depth, or conservative rules on thin inventoryCheck depth first. Rules that need age or ownership do not fire without them
Consolidation findings are missing for vSphereThose need supplied sizing dataThe live scan does not collect performance counters
The deliverable will not signNo signing key provisionedIt refuses rather than producing a signature that proves nothing