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.
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.
Step 3
Verify what happens to those records when you delete the workspace
A customer should know what BlackShield removes if the tenant-admin triggers deletion.
- 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.