​
How long does a scan take? We have 5 PB.

Less time than that number suggests, because the scanner does not read 5 PB. On the default profile it reads a 1 MiB head and a 256 KiB tail from each object it samples, capped at 2,000 objects or 4 GiB per store per run. A petabyte bucket and a gigabyte bucket cost about the same to scan. What actually drives the clock is the number of objects and the number of stores. The scanner sizes itself with this model, and it is the same one the console reports back to you: 
vCPU needed  = max( bytes ÷ (8 MiB/s × deadline) , objects ÷ (12/s × deadline) )
              capped at the number of stores — you cannot use more parallelism
              than you have stores to spread across
memory       = 2 GiB per vCPU
For 5 PB spread over 500 buckets on the default profile, the work is roughly 500 × 2,000 = one million objects and about 1.2 TiB actually read — not 5 PB.
Do not size from this page. Run once and read the verdict — the scanner measures the real work and tells you what it needed:
[inaccount] compute: 167.0 MiB across 24 store(s); about 1m on the current 1 vCPU
[inaccount] COMPUTE UNDERSIZED (ec2): 40.0 TiB across 500 store(s) needs about
            500 vCPU / 1000 GiB, beyond Fargate's 16 vCPU / 120 GiB ceiling
The same verdict travels in the report’s coverage.compute block, so a partial result always says why.
The estimate is deliberately pessimistic: it is computed against the full size of every changed object, even though only the head and tail are read. If it says you are fine, you are fine.

​
What does each profile actually read?

Objects per storeBytes per storeRowsPer-store timeCost ceilingRead per object
Sampled (default)2,0004 GiB5,00020 min$21 MiB head + 256 KiB tail
Thorough50,00064 GiB100,0001 hour$258 MiB head + 1 MiB tail
Exhaustiveunlimitedunlimitedunlimited6 hours$500whole object
Set it with DSPM_SCAN_PROFILE, or per account in Scan Configuration. Start on Sampled. It finds the same kinds of data in the same stores; what it does not do is count every instance, which matters for a record total and not for “does this bucket hold card numbers”.

​
Does the second scan re-read everything?

No, for object stores. Every run re-lists the store — that is how new and deleted objects are seen — but only objects modified since the last successful scan are read. The scan says so: 
412 object(s) unchanged since the last scan and not re-read
So a first scan of 45 objects reads 45; the next reads only what changed. Two details worth knowing:
  • Objects with no last-modified timestamp are always re-read. We cannot prove they are unchanged.
  • The high-water mark only advances after a clean scan. A run that was denied, throttled or truncated leaves it where it was, so the next run retries that window rather than skipping past data it never read.
Databases and warehouses are re-sampled in full each run, bounded by the row budget rather than by change.

​
What does it cost?

Effectively nothing for a first scan on Sampled. The two real costs:
  • The list API. Every run lists every object. At roughly $5 per million requests, a bucket with hundreds of millions of objects and no S3 Inventory is the one way to make this expensive. The scanner caps itself (DSPM_LIST_API_MAX_OBJECTS, default 1,000,000) and raises DS-COV-006 when S3 Inventory should be configured instead.
  • Compute. One Fargate task run per scan in the in-account shape. Nothing in the connected shape — those scans run on our infrastructure.

​
Do I need one scan per account, or one for the whole organisation?

One deployment per account is the simple answer, and one enrollment token can cover an AWS Organization if you leave it unpinned — the running scanner reports whichever account it woke up in. Pin the token to an account when you want a credential that can only ever file findings for that one.

​
Does anything of ours leave the account?

In the in-account shape, only a findings document. It carries classifier ids, counts, object paths and masked samples. There is no raw-value column in the product’s schema, so there is nothing to leak even by mistake. In the connected shape object contents are read across the provider API by TigerGate and classified there; what is stored afterwards is the same masked form.

​
Why is “sensitive records” blank when the store clearly holds data?

Because we sampled too little to project a total, and a 0 would read as “there is none”. The classifier found N types; it will not invent a count from a sample it does not trust.

​
Why does a store show zero findings?

Check its coverage state first. Zero findings across stores nobody could read is a coverage gap, not a clean estate — which is why every count in the console has its denominator beside it. See Troubleshooting for what each state means and what fixes it.

​
Can it read my objects without me allowing it?

No, and it is enforced in IAM rather than by the scanner promising to behave. Leave the content scope empty — ContentScanBuckets on AWS, contentScanAccounts on Azure, contentScanScope on GCP — and the role the template creates is not granted s3:GetObject at all. The scanner cannot open an object even if asked to.

​
How long until findings appear after a scan?

The scanner ships a report, the platform stages it, and a merge worker folds it in within about a minute. Scan Configuration shows merged / in flight / parked / last merged. parked means a document failed three times and will not retry on its own.

​
How do I stop it?

Delete the stack, and revoke the enrollment token in the console. Deleting the stack stops the scanning; it does not invalidate the credential.