Public Guide

What Data BlackShield Uses, Stores, and Shares

Understand exactly which record categories exist in the workspace, which ones appear in tenant-admin screens, and which legal documents cover processor and privacy commitments. Audience: Security buyers, legal teams, privacy teams, and procurement stakeholders. Typical setup time: 10-15 minutes.

trust

Use this if

Understand exactly which record categories exist in the workspace, which ones appear in tenant-admin screens, and which legal documents cover processor and privacy commitments.

Audience: Security buyers, legal teams, privacy teams, and procurement stakeholdersTypical time: 10-15 minutes

Before You Begin

  • Prepare your internal data-classification policy and vendor review checklist.
  • List the systems, scanners, and integrations that will send data to BlackShield.
  • Have `/tenant-rights` open so the current workspace data categories are visible during the review.

Guide walkthrough

1

Step 1

Start with the data categories BlackShield actually stores

The product already exposes the main record categories a tenant admin is responsible for.

  • In `/tenant-rights`, BlackShield shows counts for users, API keys, findings, remediation history, ingestion jobs, alert-sync state, and external assets.
  • Treat finding payloads, account metadata, and external-asset data as the main product data classes you are sending into the platform.
  • Decide whether your scanners or integrations are sending any sensitive metadata your team would rather keep out of BlackShield.

What success looks like

Decide whether your scanners or integrations are sending any sensitive metadata your team would rather keep out of BlackShield.

2

Step 2

Separate product-visible data scope from legal processor review

Use the product to understand data scope, and use legal documents to close processor and transfer questions.

  • Use `/tenant-rights` and the admin consoles to understand what data exists in the workspace today.
  • Use `/privacy`, `/terms`, and legal review to close processor, transfer, and contractual questions that are not visible in the UI.
  • Keep a named owner for DPA and processor review so privacy questions do not stall the rollout later.

What success looks like

Keep a named owner for DPA and processor review so privacy questions do not stall the rollout later.

3

Step 3

Verify what happens to those records when you delete the workspace

Verify the specific data categories and records that are permanently removed when a tenant administrator triggers the deletion flow.

  • The tenant deletion flow removes the current workspace's users, findings, API keys, alert-sync state, audit logs, ingestion jobs, external assets, and company record.
  • Deletion requires a typed confirmation phrase tied to the workspace slug plus an irreversible-action acknowledgement.
  • If your policy requires evidence before deletion, capture the needed audit or report exports before you run the delete flow.

What success looks like

If your policy requires evidence before deletion, capture the needed audit or report exports before you run the delete flow.

What success looks like

  • Your team can point to the actual workspace record categories BlackShield stores today.
  • Processor, transfer, and privacy questions are separated cleanly from product-visible data scope.
What Data BlackShield Uses, Stores, and Shares | BlackShield Docs