Security
Disconnecting and deleting your data
The commitment, from our privacy policy, is that product data is deleted when you disconnect a repository or delete your organisation, and on request. This page says what that means concretely, because “deleted” is a word procurement asks people to define.
Disconnecting a repository
Processing stops immediately. No further webhooks are accepted for it, no further reviews run.
What is removed: the derived conventions, findings and review history for that repository.
Deleting an organisation
Everything belonging to that organisation. Because every table carries org_id and every query filters on it, deletion is scoped by the same key isolation is — there is no separate cleanup path that could miss a table isolation covers.
What survives, and why you should ask
Two categories deserve an explicit answer rather than an implication:
Governance receipts are append-only and hash-chained. That is their whole value — a record that can be altered after the fact is not evidence. If your requirement is that receipts be destroyed on exit, say so during onboarding, because it interacts with what the chain is for.
Audit log rows are retained per GARBOARD_AUDIT_RETENTION_DAYS, which defaults to keeping them. An organisation-scoped pruner enforces whatever you set.
If either of these matters to your data-retention policy, raise it before you sign rather than at renewal — they are the two places where “we keep good records” and “we delete everything” genuinely pull against each other, and we would rather agree the answer with you than discover the disagreement later.
Self-hosted
On a self-hosted install this is entirely yours: the data is in your Postgres, and deletion is whatever your own retention tooling does. Nothing phones home, and there is no copy on our side to delete.
That is the cleanest answer to a data-residency requirement, and it is why self-hosting exists.
On request
hello@winchlabs.io. We will tell you what was removed rather than sending a confirmation that asserts it.