Who can do it
organization:delete is owner-only. An admin who runs the tenant day to
day cannot reach it — an admin who could erase the organisation could end the
organisation that appointed them — and it is not grantable to an API
key, so it needs a browser session. A leaked CI
credential that could delete the tenant would turn a key rotation into a
recovery exercise with nothing left to recover.
Two further refusals do not depend on your role:
- Your personal organisation cannot be deleted. It is where your account acts when it has nowhere else, and an account that can sign in and then act nowhere is not an outcome the product offers.
- You must type the organisation’s name back, exactly as it is stored. It is compared case-sensitively, because the point of typing it is to make you read what you are about to destroy.
1. Export your data first
Settings → Organization → Your data, or:format=json is one document; format=csv is a ZIP of four sheets — findings,
assets, policies and members — because those four have four different shapes.
Each section is capped at 10,000 rows, and the JSON names any section that was
truncated so a short export never looks like a complete one. Use the
cursor-paginated GET /findings for more than that.
The export holds no secrets: no API key material, no registry credential,
no workload key. There is no read path for a stored secret anywhere in
TRUSTIVAN, at any permission.
The audit log is not in this export. It has its own at
GET /api/v1/audit/export, which carries the hash-chain verification and the
erasure tombstones and is gated on the audit_export entitlement. Take that
one too if you need it; the envelope of the tenant export names the endpoint so
you do not conclude it is missing.
2. Schedule the erasure
Settings → Organization → Delete this organization, or:202 Accepted with the deadline. Nothing is erased by this call. It writes
a date seven days out; a background sweep carries it out afterwards.
A wrong confirm_name is a 400 — you had the authority and the guard did its
job. Your personal organisation is a 409 whatever your role.
Every member of the organisation can see the pending deletion, not only owners
(GET /api/v1/orgs/current/deletion, {"deletion": null} when none is
scheduled). A tenant should not discover its own erasure by everything
vanishing.
3. Cancel, if you change your mind
Any owner, at any point before the deadline:204 when a pending deletion was cancelled, 404 when there was nothing to
cancel — so a cancellation aimed at the wrong tenant does not report success.
Both the request and the cancellation are written to the organisation’s own
audit trail, with who asked and when.
What the erasure actually removes
When the deadline passes, the sweep cancels the subscription at the payment provider first — the customer and subscription references live on the row that is about to be deleted, and a tenant erased without that step is a customer still being charged — and then deletes the organisation row. Every tenant table referencesorganizations(id) ON DELETE CASCADE, so that
one statement removes the API keys, the workload identities, the SCIM tokens,
the single sign-on configuration, the scan schedules, the cloud accounts, the
clusters, the findings, the assets, the policies and the audit rows together. A
key that does not exist authenticates nothing; an SSO provider that does not
exist issues no membership; a schedule that does not exist never fires.
If the subscription cannot be cancelled or the erasure fails, the request is
not dropped — you asked to be deleted, and a failure must not silently
become “never mind”. The sweep backs off an hour and tries again.
What survives is a single platform-level record: the organisation’s id, name
and slug, who asked, when they asked, when it took effect, and whether it
completed. It is append-only, it holds none of your data, and it exists because
a record of an erasure that the erasure removes proves nothing.