← KhanList home · For practices
# Security Posture — KhanList **Last updated:** 2026-04-16 **Status:** Active, Phase 0 (consumer news aggregation + B2B practice waitlist) **Maintainer:** Developer (agent), reviewed by Shahid (owner) This document is the single source of truth for what data KhanList does and does not handle, what controls we have in place, and what we **explicitly do not yet have** (so readers — including prospective B2B customers and auditors — can make informed decisions). Honesty over marketing. If this doc says we don't have something, we don't have it. --- ## 1. Data scope ### 1.1 What KhanList handles today - **Public news content:** RSS/Atom feeds from 1,200+ public sources, article text, titles, publish dates, source URLs. - **Derived content:** AI-generated summaries, clusters, categorizations, and recommendations computed from the public content above. - **Newsletter subscribers:** Email addresses and subscription preferences (via Beehiiv — their terms and privacy policy apply to this data). - **Mobile-app users:** Supabase-managed account data — email, display name, preferences, push-notification tokens, device identifiers. No health or payment information. - **Analytics telemetry:** Page views, section engagement, click-throughs, aggregated cohort metrics (via PostHog). - **Admin operators:** Bcrypt-hashed credentials for admin dashboard users. - **B2B waitlist leads (new in Phase 0):** Practice name, contact name, business email, phone, specialty, marketing-spend bracket, pain-point notes. Business contact info — **not** patient data. ### 1.2 What KhanList does NOT handle - **No Protected Health Information (PHI):** No patient names, diagnoses, procedures, medications, insurance numbers, appointment records, or any information that would qualify as PHI under 45 CFR § 160.103. - **No payment card data** (no PAN, no CVV). Billing — if/when it launches — will route through Stripe and we will never see card numbers. - **No government identifiers** (SSN, driver license, passport). - **No biometric data.** --- ## 2. Encryption & transport - **In transit:** TLS 1.2+ enforced on `khanlist.com` (AWS App Runner + CloudFront managed certs). HSTS recommended (track as improvement). - **At rest:** - Primary RDS PostgreSQL database: AWS-managed encryption (aws/rds KMS key) enabled at the volume level. - S3 buckets (static assets, archival): SSE-S3 default encryption. - Secrets (DB credentials, API keys): AWS Secrets Manager. - Mobile auth tokens: Supabase-managed, encrypted at rest by Supabase. --- ## 3. Access controls - **AWS IAM:** least-privilege roles for App Runner, Lambda, and CI deployment. No long-lived access keys in code or repo (gitleaks pre-commit hook enforces this — see `.pre-commit-config.yaml`). - **Database:** App Runner connects via RDS Proxy with IAM-linked credentials. Direct DB access is restricted to admin jump paths. - **Admin dashboard:** Username/password authentication with bcrypt-hashed credentials. Role-based access (`admin` / `viewer`) via `requireAdmin` middleware. - **Mobile auth:** Supabase Auth (email/password + social OAuth via Facebook/Google). Session tokens are short-lived JWTs. - **Supabase RLS:** Row-level security policies applied to user-scoped tables (push_tokens, user_locations). Anonymous key has restricted read-only permissions. --- ## 4. Logging & audit Current state (honest assessment): - Structured application logs via Winston → stdout → App Runner log group → CloudWatch Logs (retention: default 30 days unless overridden). - HTTP request logs at the `http` level including request IDs. - Admin mutation auditing: `audit_log` table (migration `027_audit_log.ts`) plus `auditLogger` middleware records admin actions with user id, action, target. - Collection scheduler and background jobs emit metrics to CloudWatch (counts, durations, failure rates). Gaps / roadmap: - CloudTrail is enabled at account level but not fine-grained to all services yet. - No SIEM / centralized correlation. - Log retention beyond 30 days is not yet codified — recommend setting `log_group_retention_days` per-environment in CDK. --- ## 5. Data retention - **Articles:** Indefinite (we're a news archive). Soft-deleted (`status='inactive'`) for takedowns. - **Newsletter emails:** Retained until subscriber unsubscribes; then deleted on next nightly sweep (Beehiiv-managed). - **Mobile user accounts:** Retained until user requests deletion via `/delete-account` flow; then removed from Supabase within 30 days. - **Analytics events (PostHog):** Aggregated usage data may be retained indefinitely per our privacy policy. - **B2B waitlist leads (`practice_leads`):** Retained indefinitely until the contact requests removal. Status field includes `lost` and `spam` for soft-decline. - **IP addresses:** Not stored raw. `practice_leads.ip_hash` and request-log IPs are SHA-256 hashed with a server-side salt (`IP_HASH_SALT`). --- ## 6. Incident response - **Security contact:** security@khanlist.com (alias → Shahid + developer on-call). - **Reporting:** Responsible disclosure appreciated at the above address. We aim to acknowledge within 2 business days and patch critical issues within 14 days. - **Breach notification:** If a breach affecting user data occurs, we will notify affected users by email within 72 hours of confirmation and post a public post-mortem within 30 days. - **Runbook:** Internal runbook (not public) covers rotation of secrets, DB point-in-time restore, and rollback procedures. --- ## 7. What we do NOT have (as of 2026-04-16) These are deliberately called out so that B2B prospects, auditors, and users can make informed decisions. If you are considering any integration that would require any of these, talk to us first — **do not assume**: - ❌ **No HIPAA attestation.** No Business Associate Agreements are in place with AWS, Supabase, Beehiiv, PostHog, or any subprocessor. We do not handle PHI today, and until HIPAA controls are stood up, no PHI must enter the platform. See `tmp/hipaa-decision-doc-2026-04-16.md`. - ❌ **No SOC 2 attestation.** Not currently pursuing. - ❌ **No PCI-DSS scope.** We do not store card data. - ❌ **No ISO 27001 certification.** - ❌ **No formal pen-test / audit in the last 12 months.** - ❌ **No bug bounty program.** Responsible disclosure email above is the path. --- ## 8. Change log | Date | Change | Author | |------|--------|--------| | 2026-04-16 | Initial draft. Documented current data scope, explicit list of gaps, and practice_leads (B2B Phase 0) inclusion. | Developer agent | --- ## 9. For practice owners (B2B FAQ) > **Q: Is KhanList HIPAA-compliant?** > **A:** Today, KhanList handles only public marketing information — your practice name, services, location, and publicly available reviews. No PHI is transmitted or stored through our platform. We are not a HIPAA-covered entity and we do not have BAAs with our subprocessors. If and when we add features that involve PHI (patient intake with health data, scheduling integrations that pass diagnosis codes, etc.), we will stand up the full HIPAA controls (BAAs, audit, attestation) **before** shipping those features and we will be explicit about which features require the BAA layer. > **Q: Where is my practice's data stored?** > **A:** AWS US-East-1 (PostgreSQL on RDS). Encrypted at rest. Accessible to our small ops team for support. > **Q: How do I delete my data?** > **A:** Email support@khanlist.com. Full deletion within 30 days.