Public Security Baseline

Our Security Promise

Every BTS client project ships with this security baseline — documented publicly so you can verify it, audit it, and hold us to it. We exceed NSA commercial baseline recommendations for web applications.

Why publish this? Because security theater is dangerous. Publishing our baseline forces us to actually implement it — and gives you something concrete to verify before you trust us with your business data.

Application-Layer Column Encryption

Sensitive data fields (PII, financial data, health records) are encrypted at the application layer before being written to the database. Even if the database were exfiltrated, the data is unreadable without the encryption key. This exceeds standard encryption-at-rest.

Field-level AES-256 encryption before DB write
Separate key management from data storage
Decryption only at authenticated request time
Zero plaintext in database dumps or backups

Immutable Audit Logs

Every admin action is logged with timestamp, user identity, IP address, and the exact data changed. Logs are append-only and cryptographically chained so tampering is detectable. Compliant with SOC 2 and HIPAA audit trail requirements.

Append-only audit log table with row hashing
All admin mutations logged (create, update, delete)
IP address and session ID on every action
Log retention configurable per compliance requirements

Zero-Trust Authentication

Admin access is locked to a single verified email address with dual-factor entry: password + magic link. There are no shared accounts, no password resets via email guessing, and no credential stuffing surface. JWT sessions expire and rotate.

Magic-link auth via Resend (one-click, one-time)
Password + email dual-factor option
Session locked to verified email allowlist
JWT expiration and rotation (configurable)

Edge-First Architecture

All BTS client sites deploy on Vercel's global edge network. Admin API routes run as edge functions with sub-10ms latency. No long-lived servers to patch, no exposed SSH ports, no attack surface for traditional server exploits.

Vercel edge functions (no persistent server process)
Automatic TLS 1.3 on all routes
DDoS mitigation via Vercel infrastructure
HTTP security headers (CSP, HSTS, X-Frame-Options)

Secrets Hygiene

All API keys and secrets are stored in Vercel environment variables, never in code. Every secret is read with .trim() to prevent whitespace injection attacks. Environment files are git-ignored and never committed.

All secrets in Vercel project settings (not code)
Required .trim() on every secret read
.env.local permanently git-ignored
No hardcoded API keys — lint-enforced

Database Security

Vercel Postgres (Neon-backed) with connection pooling, TLS enforcement, and row-level security for multi-tenant data. Drizzle ORM prevents SQL injection via parameterized queries. Soft-delete patterns prevent accidental permanent data loss.

Neon Postgres with TLS-only connections
Drizzle ORM — no raw SQL string construction
Soft-delete pattern for critical user data
Automated backups with point-in-time recovery

Compliance Readiness

BTS projects are architected for compliance readiness. The defaults are conservative — clients opting into specific requirements (HIPAA, SOC 2, PCI) get the additional controls they need, documented in their project CLAUDE.md.

SOC 2 Type II
Audit log and access control foundations in place
HIPAA Ready
PHI encryption and audit trail for health clients (Semper Vets)
PCI Compliant
Card data never touches BTS servers — Stripe handles it
GDPR Aware
Soft-delete, data export, and right-to-deletion patterns

Questions about your specific requirements?

Ask the chat assistant, or contact Erick directly. Security requirements are scoped per project — tell me what you need to protect.

Discuss security requirements