Legal

Security Policy

Last updated: July 14, 2026

Our stance: Security is core to DoneAfter. The platform is designed around permission, proof, and release rules — nothing sensitive is released without the right trigger, approvals, and an audit trail. A single missed check-in never dumps your private data.

1. Scope

This Security Policy describes the controls we apply to DoneAfter.com and related systems that process legacy planning data. It complements the Privacy Policy and Terms of Service. Controls evolve as the product matures; some advanced measures are phased.

2. Transport and platform hardening

  • HTTPS/TLS for all traffic; HTTP redirected to HTTPS; HSTS where configured
  • Security headers including Content-Security-Policy, X-Content-Type-Options, X-Frame-Options / framing controls, Referrer-Policy, and restrictive Permissions-Policy
  • Public web root limited to public_html/; application code, configuration, and private storage kept outside the web root
  • Dotfiles and non-public paths denied at the web server layer

3. Authentication and sessions

  • Passwords hashed with Argon2id (never stored in plaintext)
  • Optional TOTP two-factor authentication for users; stronger expectations for administrative accounts
  • Email verification for account trust and sensitive scheduling where required
  • Login throttling / lockout patterns; login history retained for security review
  • Session cookies marked HttpOnly, Secure, and SameSite-appropriate; session identifiers rotated on privilege changes; idle and absolute timeouts
  • Device/session listing and revocation; alerts for notable login events where enabled
  • Emergency lockout recovery requires re-verification and is audit-logged

4. Authorization

  • Role-based access for platform roles (user, support, admin, etc.)
  • Per-item permissions for trusted contacts via roles and release rules
  • Ownership and permission checks on data access; signed tokens or verified grants for released items
  • Admin access to private content restricted, reason-tagged, and audit-logged

5. Application defenses

  • CSRF tokens on state-changing requests
  • Context-aware output escaping; HTML sanitization for rich text; CSP as defense in depth
  • PDO prepared statements for database access
  • Rate limiting on authentication, resets, emergency codes, invites, and similar endpoints
  • Explicit field allowlists to reduce mass-assignment risk
  • Upload validation (type/size), private storage with randomized names, delivery via signed links

6. Sensitive data handling

  • Encryption at rest (application-level AES-GCM) for flagged sensitive fields and files, using keys derived from server-side secrets kept out of the repository and web root
  • Tokens (sessions, resets, invites, emergency codes) stored as hashes where applicable
  • Default guidance: store instructions and locations — not raw passwords or crypto seed phrases; pattern warnings for high-risk secrets
  • Files stored in private storage; database holds metadata

7. Secure access links

Released items and downloads are delivered through purpose-scoped, time-limited, revocable signed links or access grants. Sensitive content is not emailed in the clear. Expired or revoked links fail closed.

8. Emergency card protection

Emergency codes are stored hashed; attempts are rate-limited and logged. Emergency surfaces reveal only limited, user-configured information; full sensitive release still requires the verification workflow.

9. Dead man’s switch / check-in safety

Missed check-ins do not automatically release vault contents. Escalation proceeds through reminders and trusted-contact alerts, then human verification with evidence and review. Users may cancel mistaken escalations during waiting periods where configured. Steps are logged.

10. Auditing and monitoring

Sensitive actions are recorded in append-oriented audit logs (logins with elevated privileges, privileged views, trigger decisions, releases, grants, letter status changes, account changes, exports, and similar events). Security logs capture anomalies such as failed logins and throttling. We review and alert on suspicious patterns as operational capacity allows.

11. Backups and recovery

Encrypted database backups are generated on a schedule and rotated. Private files are included in backup planning. Restore procedures aim for recovery objectives appropriate to the Service’s stage; no backup system eliminates all risk of data loss.

12. Your responsibilities

  • Use a strong unique password and enable 2FA
  • Do not upload raw seed phrases or credentials you are not authorized to hold
  • Keep contacts and addresses current
  • Review sensitive instructions with qualified professionals
  • Promptly report suspected account compromise

13. Vulnerability disclosure

If you believe you found a security vulnerability, submit a ticket via the Contact form (choose Security / abuse report) with a clear description and reproduction steps. Please act in good faith, avoid privacy violations and service disruption, and allow reasonable time for remediation before public disclosure. We appreciate responsible research.

14. Changes

We may update this Policy as controls evolve. The “Last updated” date reflects the current version.