Truestack data privacy

truestack-data-privacy

Personal data is a liability you must be able to find, justify, delete, and prove you deleted. This skill owns the privacy policy for a self-hosted single server: what counts as personal data, why you may hold it, how long, who may touch it, and how it leaves. On one box there is no managed compliance plane — the controls have to live in the schema and the code. Accuracy and provability over good intentions; abstain rather than assert a compliance claim you can't ground.

Read project memory first — CLAUDE.md is auto-loaded (Principles + Boundaries); consult .ai/memory/ for the data model, stack, and which regimes apply. If none exists, run truestack-project-memory. Keep the code↔memory tally balanced: a new data class, retention rule, lawful basis, or purge job is a recorded decision — update memory in the same change.

Auto-research, don't recall. Regulatory and standards facts drift — never state a GDPR article, CCPA/CPRA effective date, HIPAA Security Rule requirement, ENISA/NIST method, or OWASP/CVE detail from memory. Ground each load-bearing claim in an authoritative source (EDPB/ICO, the regulation text, NIST, HHS) before asserting it — the regime-specific citations behind the rules below live in references/regimes.md; re-verify them at use time. Defining a retention policy, a deletion pipeline, or crypto-shredding is consequential, often irreversible work — route the design through truestack-architecture-planning's approval gate before building. If the PreToolUse gate is wired (hooks/README.md — check it is actually installed and active), it forces a human-yes before a hard-delete / purge / key-destruction runs — verify that before relying on it; if it isn't wired, treat the approval as manual and obtain the explicit human yes yourself.

Where this skill sits: it owns the privacy policy and discipline, not the mechanics of every neighbor. truestack-quality-control runs the one-shot SAFETY pass on a change and truestack-application-security owns the security design; this skill owns the data-handling rules they enforce. truestack-observability redacts PII in telemetry but defers the classification and redaction policy to here — it implements; this skill decides what is PII. truestack-mcp-integration owns untrusted tool-output; the PreToolUse hook governs agent actions (a different layer). truestack-backend-development implements the deletion/consent APIs (and truestack-database-migrations authors the purge/erasure DDL + bounded backfill) but truestack-api-design owns their contract; truestack-architecture-planning does system design.

1. Make the PII inventory the source of truth — derive it from the schema

A spreadsheet drifts from the DB the day it's written — regulators' top recurring failures are no internal procedures and unclear retention periods (references/regimes.md). Tag every personal-data column — via column comments or a data_classification registry the code reads — with {data class, lawful basis, purpose, retention clock, deletion method}. An untagged column holding personal data is a finding.

2. Minimize — the cheapest field to protect is the one you never collected

Collect only what a stated purpose needs; don't keep "just in case" (CPRA caps retention, HIPAA expects the minimum necessary). Every field you add is inventory, retention, deletion, and breach surface — justify it against a purpose or drop it.

3. Retention = a per-record clock + a scheduled purge, never ad-hoc DELETEs

Each record carries a computed delete_after derived from its purpose — per purpose, not the longest window across all activities (a flagged regulator mistake). A daily, idempotent purge job hard-deletes expired rows and cascades into every copy — child tables, caches, search indexes, exports, denormalized views — or the PII left behind is still retained personal data.

4. Right-to-erasure: hard-delete live, suppress backups

Delete from live systems immediately. You can't surgically edit immutable backups, so log the subject in an append-only suppression/erasure list and re-apply it on every restore — an erased subject must never silently resurrect. Backups may persist until overwritten but must be put "beyond use". A refusal under an erasure exception (GDPR Art. 17(3)) needs a written case-by-case justification (references/regimes.md).

5. Pseudonymization is NOT anonymization and NOT erasure

Pseudonymized data is still personal data; only irreversible anonymization exits GDPR scope. Treat reversible tokenization/masking as a security control, never a way to dodge a deletion request, and keep the re-identification key in a separate keystore from the pseudonymized data — co-located, it's worthless.

6. Encrypt PII at rest with envelope encryption; treat key destruction as deletion

AES-256(-GCM) is the standard at-rest choice; HIPAA's proposed Security Rule update makes encryption-at-rest required, not "addressable" — verify current status (references/regimes.md). On one box the hard part is keys: never store the data key beside the ciphertext or in the same DB. Per-tenant / per-subject data keys enable crypto-shredding — destroy one key to render data unrecoverable, the only practical "erase" for immutable backups.

7. Log every ACCESS to personal data — reads included — tamper-evident and off-box

Append-only audit log capturing who / what / when / which record / why, for reads as well as writes (forensic-reconstruction grade). Ship it off-box or to a store the app user can't rewrite — a server compromise must not erase the evidence; your access log is your breach-scoping tool. Access to the audit log is itself logged.

8. Keep PII out of telemetry by contract — own the classification here

Define the policy truestack-observability enforces: deny-by-default — structured fields only, never free-text blobs; no PII in URLs, log messages, exception payloads, or trace attributes. Maintain the allowlist of safe telemetry fields here — most leaks ride in stack traces, query logs, and error-report request bodies. This skill defines what's PII; truestack-observability does the scrubbing.

9. Lawful basis and consent are first-class, queryable state — with proof and withdrawal

Don't bury consent in a boolean. Store {purpose, basis, notice/policy version shown, timestamp, source} so you can prove it, and withdrawing consent triggers the same purge pipeline as erasure. CCPA/CPRA is opt-out (sale/share + sensitive-data limits) and the Global Privacy Control signal must be honored — divergences in references/regimes.md.

10. Build the 72-hour breach machinery before you need it

A written runbook: a named decision-maker, a severity method that makes the notify / no-notify call defensible, and pre-drafted notification templates — deadlines and thresholds in references/regimes.md. Teams without one burn the first day on "who owns this?". If your audit/access logs are gone, you must assume worst-case scope.

11. Right-size to the strictest regime that actually applies — and prove deletion ran

Don't bolt on HIPAA with no ePHI; don't assume GDPR covers CCPA. Anchor the security baseline to a recognized standard (ISO/IEC 27001, NIST CSF). And attest deletion completed — a deletion receipt / log entry, not "we ran a job". "We ran a job" is not evidence.

Honest exit

This skill produces engineering guidance, not legal advice — lawful-basis determinations, Art. 17(3) refusals, and breach-notification calls need qualified counsel or a DPO; say so when one is in play. State which regimes you confirmed apply, which controls exist vs. are missing, and which compliance claims you grounded vs. couldn't verify — never assert "compliant" off an unexercised policy (honesty contract). A defensible "GDPR erasure path works; CCPA GPC handling is still a gap" beats a false all-green. Update project memory when a data class, retention rule, or basis changes; then hand off to truestack-quality-control before "done".

Explain it simply

Say what each rule protects in one plain line — "retention is a clock, not a cleanup; crypto-shredding deletes the key so the data can't be read; pseudonymized still means personal". Show the regime differences (GDPR vs. CCPA vs. HIPAA) and the field tags as a small list or table, not prose. After defining a policy, state in one line what is now provable that wasn't before.