Data Location
The Data Location report answers a simple question: where does our data actually sit? For every connection it shows the bucket and region the original data is written to; it also shows where this product's own platform lives, and what is held in your own storage versus this product's database — all on one screen.
1. Per-connection location
Each connection shows:
- Connection region — the region this AWS account connection targets
- Storage — the customer-owned S3 bucket original data is written to, that bucket's region, the prefix inside it, and the KMS key (and its region) used to encrypt it. A connection whose storage hasn't been set up yet shows these fields empty and is marked not onboarded.
- Index status — whether a Resource Explorer index exists for asset discovery, and if so, in which region. A connection that has never been checked shows unknown; one that was checked but has no index shows not indexed.
2. Platform location
Independent of any connection, the same report shows where this product's own platform sits.
- Platform region — the primary region the service runs in
- Database — this product's own database, holding summaries, hashes, and metadata (see the data class table below)
- Auth — the region of the service used for sign-in and account management
- Email — the region of the service used for notifications and invitations
- Backups — a note on backup policy (filled in by the operations team). If empty, it means the note hasn't been written yet — not that no backups exist.
3. Data class table: what lives where
The report also includes a table stating, for every kind of data, whether it lives in your own storage (tier A) or this product's database (tier B).
| Tier | Data class |
|---|---|
| A (your own storage) | finding bodies, asset properties, IAM documents, policy bodies, control report bodies, manual evidence files, access review snapshots and reports, evidence packages (zip) |
| B (this product's database) | summaries and aggregates, hashes, manifests, audit events, execution ledger |
Every tier-A item sits in a bucket you own, encrypted with a KMS key you manage. This product's own database keeps only a pointer to that original, its hash, and the summary figures shown on screen — never a copy of the original itself.
Both tiers follow the evidence retention policy, three years by default (adjustable by organization policy).
4. Availability checks: what "missing" means
Requesting the report with availability included asks each owning service to sample a handful of the tier-A originals it has written and read them back. The result comes back as one of:
- OK — every sampled item was read successfully (this also covers the case where nothing has been produced yet, so the sample is zero).
- Degraded — some items could not be read. A list of missing examples shows which ones.
- Not onboarded — this connection's storage hasn't been set up yet.
- Unavailable — the owning service itself couldn't be reached to check.
"Missing" means this product wrote that file at some point, but cannot read it back from your bucket now — the object may have been deleted or renamed on your side, or a key permission may have changed. An availability check never blocks report generation — it's an observation, not an input, so the report is still produced with the finding stated plainly inside it.
5. Scopes
A Data Location report can be requested at three scopes:
- A single connection — the Data Location tab under project settings
- A connection group — the Data Location tab on the group page
- The whole tenant — the Data Location tab under organization settings (since this exposes every connection's bucket and key information at once, it's limited to admins and auditors with the relevant access)
6. Exporting a PDF
At any scope, Export to PDF produces a document — suitable for attaching to a contract annex or handing directly to an auditor. To receive it bundled with the control report, access reviews and audit history as a single signed package, see Evidence Package.