How we protect your data

Every tenant-facing table has Postgres Row Level Security policies that enforce:

• A landlord can only read rows where organization_id matches an org they own.
• A tenant can only read rows tied to their own tenant_id.
• Service-role writes (Stripe webhooks, cron) are explicitly scoped and audited.

RLS is evaluated by Postgres itself, which means a bug in our application code still can't expose another landlord's data.

• In transit: TLS 1.2+ everywhere, HSTS on tenant-assist.com.
• At rest: AES-256 on Postgres storage (Supabase/AWS), encrypted object storage for uploaded photos and lease documents.
• Secrets: API keys stored as SHA-256 hashes; webhook signing secrets are per-endpoint, generated at creation.
• Passwords: hashed via Supabase Auth (bcrypt with per-user salts).

• Email + password auth via Supabase, with optional magic-link sign-in.
• Session cookies are HttpOnly; Secure; SameSite=Lax.
• All landlord API routes verify role + org ownership before returning data.
• Vendor portal uses single-use magic tokens (no login for vendors) with 30-day expiry.

• Every lease signature is recorded with IP, user agent, typed name, and a SHA-256 hash of the rendered document.
• Stripe webhook deliveries and outbound TenantAssist webhooks are logged with attempt counts and last error.
• Admin writes to billing columns are blocked at the database level for landlord JWTs; only service role can write.

We target a <1-hour acknowledgment, <4-hour mitigation, and <72-hour customer notification window for anything that touches customer data. Incidents are posted to /trust.

Report a suspected issue to tenantassist@protonmail.com — responsible disclosure is welcomed and we do not pursue legal action against good-faith researchers.

• Least-privilege: production database access is limited to two maintainers.
• All engineer access is 2FA-enforced and logged.
• Production secrets are stored in Cloudflare secret bindings, never in git.
• Backups are encrypted and retained for 30 days.