Everything on this page lives in Data Security → Scan Configuration, per
cloud account.
Scan depth
| Depth | Reads |
|---|
| Inventory and configuration only | Control-plane APIs. No object is opened. This is the default. |
| Read object content in the scope below | Opens objects in the stores the scope matches. |
What to read
Scope decides which stores are opened:
- Scan every data store — every discovered store, subject to exclusions.
- Everything publicly exposed — only stores reachable from the internet.
- Include by name — one glob per line, for example
prod-* or *customer*.
- Include by tag — one
key=value per line; * matches any value.
- Exclude by name — exclusions win over inclusions. A store matched by both
is not read.
An empty scope means nothing is read. The default is deliberately off rather
than everything.
Narrowing to particular services
Under Services and resources, a scan can be narrowed twice: to particular
services, and to particular resources inside them. The two are separate
questions — “only look at S3” changes which APIs are called and what a denial
means, while “only look at prod-data” filters the result.
Inventory and content are scoped independently, because the common
configuration is inventory everything, read only one bucket.
| Empty means | Effect |
|---|
| Inventory and configuration | every service | Narrowing saves API calls. Anything deselected is reported as excluded by configuration, never as a service that came back empty. |
| Content scanning | every service | Only services with a content reader are offered — a metadata-only service would otherwise promise a classification result that can never arrive. The name and exposure rules under What to read still apply on top. |
Empty means everything here, and empty means nothing three fields away
under What to read. That is not an inconsistency: narrowing an inventory is
a choice you make explicitly, while content scanning spends your money, so its
default is off. Both controls say which they are.
How much of each store to read
Scope decides which stores; the profile decides how far into each one. This is
the setting behind “a large bucket reported only a few objects”.
| Profile | Per store | Use when |
|---|
| Sampled | 2,000 objects · 4 GiB · 20 min | The default. Characterises a store from a stratified sample — enough to know what kind of data it holds. Every published cost figure assumes this. |
| Thorough | 50,000 objects · 64 GiB · 60 min | A sample found something and you need confidence in how widespread it is. |
| Exhaustive | Every object, read whole | Not better sampling — a different cost model. On a large estate this is the difference between dollars and thousands. |
A store that reaches its cap is recorded as budget_exhausted — read in part,
never reported as clean. Raising the profile is how you finish it.
Database access
Buckets are read with the role you already granted. A database is not: it needs
a user to connect as, and that user is yours.
- Connect as user — the read-only user you granted
SELECT. Required even
for the passwordless methods, because they sign a token for a user.
- How we authenticate — IAM database authentication on AWS, workload
identity on GCP, Microsoft Entra on Azure. There is then no password to store,
rotate or leak.
- Require TLS — leave it on. The rows read here are the sensitive ones by
definition.
For the in-account shape this is set in your Terraform instead, because the
scanner runs inside your account and never reads console configuration.
Frequency
Inventory and content have separate intervals. Inventory is cheap and can run
often; content opens objects and is billed per read, so it runs on its own,
slower schedule.
Scans are incremental: a store is re-read only where objects changed since the
last run.
Reading coverage states
| State | Means |
|---|
ok | Read and classified. |
never | Not yet read. Not the same as clean. |
budget_exhausted | Read up to the configured profile’s cap. |
unsupported_format | Reached and opened, but the content could not be parsed. |
denied | The credential was refused. A permission problem, not an empty store. |
unreachable | Could not be connected to — commonly a private database with no network path. |
ok with no classifications means “we looked and found nothing”. Every
other state means we did not finish looking, and the console keeps them apart on
purpose.
Why sensitive record counts can be empty
The Sensitive records column estimates how many records are at stake, by
projecting matches in the sample onto the store’s total population.
For warehouses and databases the engine reports a row count to project onto.
For object stores the projection comes from the enumeration instead — records
found per object sampled, scaled by the number of objects the store holds. A
store whose objects were all opened is not projected at all; it is counted, and
labelled as exact.
The estimator refuses to extrapolate from a sample of fewer than 50 records,
where the interval would swamp the point estimate. Below that floor the column
reads —, not 0.
That distinction is deliberate and worth stating plainly: 0 would be a claim
that the store holds no records of that type, and a sample of twelve does not
support it. The families found are still shown — only the count is withheld.
A blank record count therefore means one of two things, and neither is an
error: no content scan has run for that store yet, or the sample was too small
to project from. If a store shows a count with a small + beside it, some of
its data types were projected and others were not — the total is a floor
rather than a whole.
