docs: add a consolidated Data Deletion page (FIL-894)

docs/billing/trial.mdx

@@ -45,7 +45,7 @@ You can upgrade to a paid plan at any time during the trial or grace period. Upg
 :::
 
 :::info What "disabled" means
-Disabling blocks all access to the account: your data is no longer reachable through the API or the dashboard, and access keys stop working. Fil One does not run an automatic purge at this point, so contact support if you need access restored or your data removed.
+Disabling blocks all access to the account: your data is no longer reachable through the API or the dashboard, and access keys stop working. A disabled account can be restored. Erasure is a separate request handled by support rather than something closure does automatically. Contact support either way. See [Data Deletion](/security/data-deletion) for the full account-closure picture.
 :::
 
 ## Paid plan pricing

docs/faq.mdx

@@ -122,7 +122,9 @@ Fil One does not currently expose per-object proof data — content identifiers,
 <summary>What happens to my data if I delete it?</summary>
 <div>
 
-When you delete an object or bucket, it is immediately removed from your Fil One account and is no longer accessible via the API or dashboard. Because Filecoin stores data in sealed sectors, the underlying storage may persist for a bounded period until the sector naturally expires — an infrastructure detail set by the storage layer, not a user-facing state. That residual data stays encrypted, with key custody held by the regional storage operator rather than by you or Fil One (see [Encryption](/security/encryption)). The data is inaccessible through Fil One from the moment of deletion.
+When you delete an object or bucket, it is immediately removed from your Fil One account and is no longer accessible via the API or dashboard. Because Filecoin stores data in sealed sectors, the underlying storage may persist for a bounded period until the sector naturally expires. That residual data stays encrypted, with the key held by the regional storage operator, and is unreachable through Fil One from the moment of deletion.
+
+Closing an account revokes access rather than erasing data. Erasure is a separate request handled by support. For the full picture, including versioned buckets, Object Lock, account closure, and residual data, see [Data Deletion](/security/data-deletion).
 
 </div>
 </details>

docs/security/data-deletion.mdx

@@ -0,0 +1,78 @@
+---
+title: Data Deletion
+description: What happens when you delete an object, a bucket, or close your account.
+---
+
+This page is the single reference for what deletion means in Fil One: at the object level, the bucket level, and the account level. If you are answering a due-diligence questionnaire or a data-subject request, start here.
+
+The short version: **deletion in Fil One removes your access immediately.** Because storage is fulfilled by the Filecoin network, the underlying encrypted bytes may persist in a sealed sector for a bounded period afterward, and closing an account blocks access rather than purging data. Both behaviours are described in full below.
+
+## Deleting an object
+
+On a bucket **without** versioning, deletion is immediate. The object disappears from the dashboard and the API at once, and there is no recycle bin or soft-delete to recover it from.
+
+On a **versioned** bucket, a delete request without a version ID places a **delete marker** instead. The object stops appearing in listings and `GetObject` returns `NoSuchKey`, but prior versions remain intact, remain downloadable by version ID, and **continue to count as stored storage for billing**. To remove a version permanently, delete it by its version ID. See [Versioning](/storage/versioning).
+
+Deleting the delete marker itself makes the object visible again.
+
+## Deleting a bucket
+
+Bucket deletion from the dashboard is not yet available. The delete button is visible but disabled while the underlying storage layer completes support for it.
+
+Over the S3 API, `DeleteBucket` is available in `us-east-1` with a key holding the `DeleteBucket` permission. The bucket must be empty. It is not available in `eu-west-1`. See [Buckets](/storage/buckets).
+
+## Deletion under Object Lock
+
+An object with active retention cannot be deleted: the request returns `403 AccessDenied`.
+
+In **Compliance** mode this holds for every caller, including the account owner, regardless of what permissions their key carries. In **Governance** mode, which standard S3 lets a caller override if they hold a special bypass permission, Fil One does not hand out that bypass, so Governance-locked objects are also protected for their full retention period.
+
+On a versioned bucket a delete marker can still be placed over a locked object: the object appears deleted to applications while the underlying version stays protected and intact until retention expires. See [Object Lock](/storage/object-lock).
+
+## Closing an account
+
+When a trial expires (after its grace period) or a paid subscription is cancelled and its grace period ends, the account is **disabled**: your data becomes unreachable through both the API and the dashboard, and access keys stop working.
+
+Closing an account revokes access; erasing data is a separate, explicit step. That gives you two paths:
+
+- **To regain access,** contact support. A disabled account can be restored.
+- **To request erasure,** contact support. Erasure is not a self-service action and does not happen automatically when an account closes.
+
+:::note Closure is not erasure
+Closing an account disables it and blocks access. It does not delete your stored data, and no erasure happens automatically.
+
+If you have a specific erasure requirement, particularly one with a regulatory deadline, contact support to confirm what applies to your account before relying on it in a compliance process.
+:::
+
+If you are documenting this for a retention or privacy review, record account closure as **access revocation rather than erasure**, with erasure handled as a separate support request.
+
+## Residual data on the Filecoin network
+
+Filecoin stores data in **sealed sectors**. When you delete an object, it becomes inaccessible through Fil One immediately, but the bytes inside an already-sealed sector may persist until that sector naturally expires. The exact duration is set by the storage layer, not measured or controlled by Fil One.
+
+Two things are true of that residual data:
+
+- **It stays encrypted, and the key is held by the regional storage operator** rather than by you or Fil One (see [Encryption](/security/encryption)).
+- **It is not reachable through Fil One.** There is no API or dashboard path to it from the moment of deletion.
+
+This is a property of how the underlying network stores data, not a Fil One retention policy, and it does not affect your ability to manage data in your account.
+
+For questions about how the underlying network handles deleted data, such as replication or the proof cycle that storage providers run, contact support and we will get you a direct answer.
+
+## Account data beyond your stored objects
+
+Everything above describes the objects you store. Account closure also involves records that Fil One itself holds, and the statements above do not cover them:
+
+- **Profile, billing, and access-key records.** These live in Fil One's own systems rather than at the regional storage operator, under **different encryption and key-custody arrangements** than your object data. "Encrypted, with the key held by the storage operator" is a statement about object data specifically.
+- **Operational logs.** Logs retained for debugging and support can contain account identifiers for a period after closure.
+- **Your browser session.** The sign-in cookie holds a *signed*, not encrypted, identity token, so the identity claims inside it (including the account email address) are readable by anyone who has the cookie. Sign out and clear site data on shared machines.
+
+If you are making an erasure request, say explicitly whether it covers **only stored objects** or **account records as well**, since these are handled separately.
+
+## Limits of these guarantees
+
+- **No cryptographic proof of deletion.** Fil One surfaces no per-object CID, deal ID, or seal state, so there is nothing you can present to an auditor to demonstrate that a specific object was destroyed.
+- **No guaranteed key destruction.** Deleting data removes your access to it. Fil One does not guarantee that the encryption key is destroyed as part of that, so treat deletion as loss of access rather than as cryptographic destruction. If your compliance process depends on key destruction, contact support.
+- **No guaranteed destruction timeline.** The bounded sealed-sector persistence above is set by the storage layer, and Fil One does not publish a maximum.
+- **No automated erasure on account closure.** Closure disables access. Erasure is a separate request handled by support.
+- **No determination of regulatory sufficiency.** Whether this deletion behaviour satisfies a specific obligation (GDPR erasure, a retention schedule, a DSAR deadline) is a question for your own compliance review.

sidebars.js

@@ -32,6 +32,7 @@ const sidebars = {
         "security/authentication",
         "security/api-keys",
         "security/encryption",
+        "security/data-deletion",
       ],
     },
     {

static/llms-full.txt

@@ -512,7 +512,9 @@ from your Fil One account. Because Filecoin stores data in sealed sectors, the
 underlying storage may persist for a bounded period until the sector naturally
 expires (duration set by the storage layer). That residual data stays encrypted,
 and key custody sits with the regional storage operator rather than with you or
-Fil One. This does not affect your ability to manage your data in Fil One.
+Fil One, so this is LOSS OF ACCESS rather than cryptographic destruction (key
+destruction is not guaranteed). This does not affect your ability to manage your
+data in Fil One.
 
 
 ---
@@ -1034,7 +1036,8 @@ Because Filecoin stores data in sealed sectors, the underlying storage may
 persist for a bounded period until the sector naturally expires; the exact
 duration is set by the storage layer rather than measured by Fil One. That
 residual data stays encrypted, and key custody sits with the regional storage
-operator rather than with the customer or Fil One.
+operator rather than with the customer or Fil One, which means LOSS OF ACCESS
+rather than cryptographic destruction (key destruction is not guaranteed).
 
 ## Common use cases
 
@@ -1312,6 +1315,112 @@ Client-side encryption is in addition to the server-side encryption that Fil One
 applies automatically.
 
 
+---
+
+# Data Deletion
+
+Source: https://docs.fil.one/security/data-deletion
+
+Single reference for what deletion means at the object, bucket, and account
+level. Short version: deletion removes your access immediately; because storage
+is fulfilled by the Filecoin network the underlying encrypted bytes may persist
+in a sealed sector for a bounded period afterward; and closing an account blocks
+access rather than purging data.
+
+## Deleting an object
+
+On a bucket WITHOUT versioning, deletion is immediate, with no recycle bin
+and no soft-delete.
+
+On a VERSIONED bucket, a delete without a version ID places a DELETE MARKER
+instead. The object stops appearing in listings and GetObject returns NoSuchKey,
+but prior versions remain intact, remain downloadable by version ID, and
+CONTINUE TO COUNT AS STORED STORAGE for billing. To remove a version
+permanently, delete it by its version ID. Deleting the delete marker makes the
+object visible again.
+
+## Deleting a bucket
+
+Dashboard bucket deletion is not yet available (button visible but disabled
+while the storage layer completes support). Over the S3 API, DeleteBucket works
+in us-east-1 with a key holding the DeleteBucket permission and an empty bucket;
+it is not available in eu-west-1.
+
+## Deletion under Object Lock
+
+An object with active retention cannot be deleted: 403 AccessDenied. In
+Compliance mode this holds for every caller including the account owner,
+regardless of key permissions. In Governance mode, which standard S3 lets a
+caller override with a special bypass permission, Fil One does not hand out
+that bypass, so Governance-locked objects are equally protected for their full
+retention period. A delete marker can still be placed over a locked object: it
+appears deleted while the underlying version stays protected.
+
+## Closing an account
+
+When a trial expires (after its grace period) or a paid subscription is
+cancelled and its grace period ends, the account is DISABLED: data becomes
+unreachable through the API and dashboard, and access keys stop working.
+
+Closing an account revokes access; erasing data is a separate, explicit step.
+Two paths: to regain access, contact support (a disabled account can be
+restored); to request erasure, contact support (not self-service, and NOT
+automatic on closure).
+
+⚠️ CLOSURE IS NOT ERASURE. There is no automated purge: closing an account
+disables it and blocks access, it does not delete stored data. Erasure is a
+separate SUPPORT REQUEST. Anyone with a specific erasure requirement, especially a
+regulatory deadline, should confirm with support what applies to their account
+before relying on it.
+
+For a retention or privacy review, record account closure as ACCESS REVOCATION
+RATHER THAN ERASURE, with erasure handled as a separate support request.
+
+## Residual data on the Filecoin network
+
+Filecoin stores data in sealed sectors. A deleted object becomes inaccessible
+through Fil One immediately, but bytes inside an already-sealed sector may
+persist until that sector naturally expires, with the duration set by the storage layer
+not measured or controlled by Fil One. That residual data stays encrypted (key
+custody with the regional storage operator) and is not reachable through Fil One
+from the moment of deletion. This is a property of the underlying network, not a
+Fil One retention policy.
+
+⚠️ "STAYS ENCRYPTED" IS NOT THE SAME AS "UNRECOVERABLE", since the operator
+holding the residual sector also holds the key. KEY DESTRUCTION IS NOT GUARANTEED,
+so present deletion as LOSS OF ACCESS rather than cryptographic destruction. Note
+also the structural limit: where a key covers a whole bucket rather than an
+individual object, deleting one object cannot destroy that key, because the
+bucket's other objects still need it.
+
+For questions about how the underlying network handles deleted data, such as
+replication or the proof cycle storage providers run, contact support.
+
+## Account data beyond stored objects
+
+Account closure also involves records Fil One itself holds, which the statements
+above do NOT cover: profile, billing and access-key records (held in Fil One's own
+systems, under DIFFERENT encryption and key-custody arrangements than object
+data); operational logs, which can retain account identifiers for a period after
+closure; and the browser sign-in cookie, which holds a SIGNED (not encrypted)
+identity token, so its claims including the account email are readable by anyone
+holding the cookie. An erasure request should state explicitly whether it covers
+only stored objects or account records too, since they are handled separately.
+
+## Limits of these guarantees
+
+- No cryptographic proof of deletion: no per-object CID, deal ID, or seal state
+  to present to an auditor.
+- No guaranteed key destruction: deletion removes access, and Fil One does not
+  guarantee the encryption key is destroyed as part of it.
+- No guaranteed destruction timeline: no published maximum for sealed-sector
+  persistence.
+- No automated erasure on account closure: closure disables access, and erasure is
+  a separate request handled by support.
+- No determination of regulatory sufficiency (GDPR erasure, retention schedules,
+  DSAR deadlines) is for your own compliance review.
+
+
 ---
 
 # Pricing
@@ -1356,7 +1465,7 @@ The two caps are enforcement thresholds, not soft allowances, and behave differe
 | Grace period | 31-37 | Read-only. Download your data and upgrade. |
 | Expired | 38+ | Account disabled. No access to data, uploads, or API keys. |
 
-You can upgrade to a paid plan at any time during the trial or grace period. Disabling blocks all access to the account; Fil One does not run an automatic purge at that point, so contact support to restore access or request removal of your data.
+You can upgrade to a paid plan at any time during the trial or grace period. Disabling blocks all access to the account; a disabled account can be restored. Erasure is a SEPARATE SUPPORT REQUEST, not something closure does automatically. Contact support either way.
 
 ## Paid plan pricing
 
@@ -2770,8 +2879,9 @@ bounded period until the sector naturally expires (duration set by the storage
 layer), but the data is inaccessible from the moment of deletion. That residual
 data stays encrypted, and key custody sits with the regional storage operator
 rather than with you or Fil One. Note: account
-closure does NOT purge data — the account is disabled and access blocked, and
-no automatic purge runs; contact support to request removal.
+closure revokes access rather than erasing data — the account is disabled and
+access blocked; erasure is a separate request via support. See the Data Deletion
+page for the full picture.
 
 **Can multiple users access the same account?**
 Currently accounts are single-user. Multi-user organization accounts with RBAC

static/llms.txt

@@ -133,6 +133,16 @@ Critical integration notes for developers:
   the regional operator (no customer-managed keys, cipher unconfirmed).
   Client-side encryption is up to you — AWS's S3 Encryption Client exists only
   for Java/.NET/Go/Ruby, NOT boto3/CLI/JS v3
+- [Data Deletion](https://docs.fil.one/security/data-deletion): single reference
+  for deletion semantics: object delete (immediate on non-versioned, delete
+  marker on versioned), bucket delete, deletion under Object Lock (Compliance
+  binds every caller; Governance has no bypass so it is equally protected),
+  account closure (revokes ACCESS, NOT erasure; no automated purge; erasure is a
+  separate support request), residual encrypted data in sealed sectors (key held
+  by the OPERATOR, so loss of access rather than cryptographic destruction, and
+  key destruction is NOT guaranteed), account records beyond objects (different
+  key custody; signed-not-encrypted session cookie).
+  No cryptographic proof of deletion
 
 ## Billing