Security Overview

1. Data Classification

Public Data

All education data from NCES CCD, CRDC, SAIPE, E-Rate, EdFacts — publicly available federal datasets. This is the core of what ThinkKits processes.

User Account Data

Email, name, organization (collected during signup via Clerk). Minimum necessary principle.

Payment Data

Handled entirely by Stripe. ThinkKits never sees, stores, or processes credit card numbers. PCI DSS compliance through Stripe.

No Student PII

ThinkKits does not collect, access, or store any information that identifies individual students.

2. Infrastructure Security

3. Encryption

At Rest

AES-256 encryption for all data stored in Supabase Postgres (transparent data encryption) and Neo4j data on Railway (encrypted volumes).

In Transit

TLS 1.3 enforced on all connections via Cloudflare edge. HTTP Strict Transport Security (HSTS) headers. Certificate auto-renewal via Let's Encrypt / Cloudflare.

API Keys

Environment variables stored in Railway's encrypted secrets vault. Never committed to source code. Rotated on personnel change or suspected compromise.

User Passwords

Handled by Clerk — bcrypt hashing, never accessible to ThinkKits application code.

4. Authentication & Access Control

• User Authentication: Clerk-powered with email/password and social OAuth
• MFA: Available for all accounts, required for admin accounts
• Session Management: JWT tokens with configurable expiration, automatic session cleanup
• API Authentication: API key-based (X-API-Key header) with tier-based rate limiting
• Admin Access: Role-based access control, admin panel restricted to authorized personnel
• Rate Limiting: Per-tier limits (Explorer: 3/day, Starter: 25/day, Pro: 100/day, Business: unlimited)

5. Application Security

• Content Security Policy (CSP) headers
• CORS restrictions to allowed origins
• Input validation and parameterized queries (SQL injection prevention)
• XSS protection via Content-Type headers and output encoding
• CSRF protection on state-changing operations
• Dependency scanning via GitHub Dependabot
• Security headers: X-Content-Type-Options, X-Frame-Options, Referrer-Policy

6. Data Backup & Disaster Recovery

• Supabase: Automated daily backups with point-in-time recovery (30-day retention per Supabase plan)
• Neo4j (Railway): Volume snapshots and/or scheduled exports (per ops runbook)
• Pinecone: Replicated across availability zones (per Pinecone Serverless architecture)
• RPO / RTO targets: Published as contractual RPO/RTO commitments only on signed Business-tier SLA addendums. Our internal target is a sub-24h RPO and sub-4h RTO; formal DR runbooks and periodic restoration drills ship as part of the SOC 2 Type II program.

7. Audit Logging

• All API requests logged with timestamp, user ID, endpoint, and response code
• Authentication events (login, logout, failed attempts) tracked via Clerk
• Admin actions logged in audit trail (viewable in admin panel)
• Retention: 3+ years for compliance records
• Logs stored in Railway's managed logging infrastructure

8. Vulnerability Management

• Responsible Disclosure: Public bug bounty program (see vulnerability-report.html)
• Dependency Updates: GitHub Dependabot for automated security patches
• Code Review: All changes reviewed before deployment
• Penetration Testing: Planned for Q3 2026 (pre-StateRAMP)
• Incident Response: Documented IRP (see incident-response.html)

9. DDoS Protection & Rate Limiting

• Cloudflare enterprise DDoS mitigation on all endpoints
• Application-level rate limiting per API tier
• Automatic IP blocking for abuse patterns
• Geographic restrictions available for enterprise customers

10. Compliance Posture

11. Third-Party Security

All vendors evaluated for SOC 2 Aligned or equivalent certification. Data processing agreements in place with all sub-processors.

Vendor list: Clerk, Stripe, Supabase, Neo4j, Pinecone, Railway, Cloudflare, Sentry, UptimeRobot

12. Contact