← Ataski · Trust & security · DPA · Subprocessors

This is the canonical English version. Native translations for DE / ES / FR / PT / RU are pending counsel sign-off.

Approved 2026-10-08

Media and Equipment Disposal Policy

Owner: the founder. Approved: 2026-10-08. Review: annually, and on any significant change — a new kind of device, or a new provider holding data.

Scope: destroying data when the thing that holds it is retired — a cloud resource, a disk, a laptop, a phone. Deleting a customer's data when the customer leaves is a different procedure: docs/runbooks/offboarding.md, under data-retention.md.

1. Cloud media — the provider's job

Ataski owns no servers and no disks in any data centre. When Hetzner, Neon or Cloudflare retires a physical disk that held our data, sanitising or destroying it is the provider's obligation under its own security programme and its DPA with us (vendor-management.md). Our evidence is the provider's own audit report, collected at the annual vendor review — which has not yet been performed, so no such report is on file today.

2. Cloud resources Ataski retires itself

Resource How it is retired
Application server Bring up and verify the replacement first. Delete the server and its snapshots and backups in the Hetzner console. Then rotate every credential that was in its environment file — the disk was not encrypted and we cannot watch what happens to it next (docs/runbooks/secret-rotation.md).
Neon branch or project Delete it in the Neon console. Point-in-time history expires on Neon's retention window. The restore drill is built to delete its own branch.
R2 objects or bucket Delete them. There is no versioning, so deletion is final.
A vendor account Request deletion of the data under the vendor's DPA, record the confirmation, and follow vendor-management.md §4.

3. The founder's laptop and phone

Before it leaves your hands — sold, given away, recycled, returned, or sent for repair:

  1. Nothing to rescue. The code is on GitHub. .env.local is never copied to the next machine; its values are re-issued from the vendor consoles.
  2. Revoke what the device could use. Remove its SSH public key from the server's authorized_keys; sign it out of every vendor console and the company mailbox; remove it as an MFA factor where it is one.
  3. Rotate the production database credentials .env.local held — it points at production. Rotate the rest of .env.local too if the device was out of your control at any point.
  4. Wipe. With full-disk encryption on: Windows Reset this PC → Remove everything, with Clean data turned on, or the SSD maker's secure-erase tool. A phone: the factory reset, with its encryption on (the default on current phones). A device that will not boot: remove the drive and keep it, or have it physically destroyed.
  5. Repair: remove the drive or wipe it first. Never hand over a device with a session open.
  6. Record it in the disposal log, docs/security/asset-inventory.md §7: date, device, method, what was revoked.

Lost or stolen: this is an incident, not a disposal. Follow docs/runbooks/secret-rotation.md §4 — rotate everything .env.local held, database first; remove the SSH key; revoke console sessions — and open the incident record (docs/legal/incident-response-plan.md).

4. Removable media and paper

None is used for Customer Data. If a removable drive ever must hold any, it is encrypted, wiped under §3 step 4 the same day the need ends, and recorded.

5. Not in place today