EVEN Trust Center
Security at EVEN
How we protect fans, artists, and the data they trust us with.
Last updated: 2026/07/15
About EVEN
EVEN is a music platform where artists sell releases, subscriptions, livestreams, and merch directly to fans. We handle payments (via Stripe), streaming media (via Mux and S3-backed CDN), messaging, and fan analytics. Security is foundational to that trust: fans share payment information, artists share unreleased music, and both expect the platform to protect them.
This page describes how we protect customer data and systems. It is maintained by EVEN’s Engineering team and reviewed quarterly.
Compliance & certifications
EVEN’s compliance posture as of 2026:
SOC 2 Type II
In progress (observation window opens 2026). Managed via Vanta; auditor engaged; policies, controls, and tests being validated.
GDPR
In effect. EU/EEA data subject rights honored; DPA available on request; sub-processor register maintained.
CCPA / CPRA + PCI DSS
CCPA / CPRA in effect. California resident data rights honored via privacy@even.biz. PCI DSS is Not applicable — SAQ A. Cardholder data never touches EVEN infrastructure; all card data flows through Stripe’s hosted checkout.
Trust materials (SOC 2 report, DPA, sub-processor list) are available under NDA — contact security@even.biz.
Infrastructure & hosting
EVEN runs on a fully cloud-native stack. There is no corporate office network, no VPN, and no on-premise hardware to attack. Every production system is provider-managed by a SOC 2-certified vendor.
Where things run
System
Provider
Region / Notes
Public frontends (fan / artist / studio apps)
Vercel (Edge Network)
Global edge, US-hosted compute
API and admin apps (Rails)
Render
Oregon (us-west)
Background workers
Render (Sidekiq)
Oregon (us-west)
Production database
PlanetScale (MySQL / Vitess)
AWS us-west-2, 3 AZs, primary + 2 replicas
Media storage & CDN
AWS S3 + CloudFront
us-east-1 primary, us-west-1 replication
Cache / job queue
Render Redis (internal-only)
Oregon (us-west)
Payments
Stripe (including Connect for payouts)
External SaaS
Streaming media
Mux (signed URLs)
External SaaS
Redundancy & availability
• Database: PlanetScale primary + 2 replicas across 3 AWS availability zones; daily automated backups.
• Media: S3 cross-region replication from us-east-1 to us-west-1.
• Application: Render and Vercel provide managed high-availability with automatic failover.
• Business continuity and disaster recovery plans are exercised annually via tabletop exercise (most recent: 2026).
Data encryption
In transit
• All external traffic is TLS 1.2+ (TLS 1.3 preferred) — provider-managed certificates at Vercel edge, CloudFront, and Render load balancers.
• Database connections use TLS with certificate verification (verify_identity mode).
• Webhook traffic (Stripe, Mux, Transloadit, Shopify) is verified via provider-issued signatures before processing.
At rest
• PlanetScale: encrypted at rest with provider-managed keys (AES-256).
• AWS S3: server-side encryption enabled on all media, log, and DDEX partner buckets.
• Render Postgres and Redis: encrypted at rest by the platform.
• Application secrets are stored as encrypted environment variables in Render and GitHub Actions (never checked into source).
Access control & identity
Access to production systems is granted on a least-privilege, business-need basis and reviewed quarterly.
Employee & contractor access
• Workforce identity is managed via JumpCloud (SSO + MDM).
• Full-disk encryption (FileVault / BitLocker) is required on every in-scope employee device.
• A company-managed password manager is required for all in-scope employees.
• Multi-factor authentication is enforced on GitHub, Render, PlanetScale, AWS, Vanta, Google Workspace, and Stripe.
Production access is gated at four independent layers
GitHub
GitHub Actions
Render
PlanetScale
Four independent layers protect production. A single individual cannot unilaterally deploy.
• GitHub — branch protection on main: mandatory pull-request review, mandatory CI green, no direct pushes, no force pushes.
• GitHub Actions — deploy workflow triggered only by merges to main; secrets scoped to protected workflows.
• Render — admin/deploy access limited to the engineering lead and one designated backup.
• PlanetScale — schema changes require an explicit deploy request review before applying to production.
Fan & artist access
• Passwordless authentication via Magic Link (short-lived tokens over TLS) — no password storage on EVEN’s side.
• Session tokens are scoped, expiring, and rotated.
• Authorization is enforced server-side via Pundit policies; every API endpoint is scoped to the acting user’s role and resource ownership.
Access reviews
• Quarterly access review across GitHub, Render, PlanetScale, and AWS by the engineering lead.
• Same-day revocation on employee/contractor offboarding across all four systems, independent of the quarterly cadence.
Secure development lifecycle (SDLC)
Every change to production code and infrastructure is authorized, documented, tested, reviewed, and approved before it ships.
01
Propose — Code changes are proposed via GitHub pull requests; a single individual cannot unilaterally deploy.
02
Review — Every PR requires at least one approving review from another engineer before merge.
03
Test — Every PR must pass automated CI: RSpec (both API and admin apps), RuboCop static analysis, and dedicated security checks.
04
Approve — Every schema change requires a separate PlanetScale deploy-request approval on top of the code PR review.
05
Deploy — Merges to main automatically trigger production deploys via a signed GitHub Actions workflow.
06
Monitor — Security-relevant dependency bumps are triaged and merged with the same review + CI gates as feature work.
Database schema changes
• Schema migrations are additive-only and backward-compatible with running code (verified against PlanetScale’s declarative deploy-request model).
• Every schema change requires a separate PlanetScale deploy-request approval on top of the code PR review.
• Rollback procedures are documented per service; databases are point-in-time recoverable via provider backups.
Emergency changes
• Emergency-fix carve-out exists for P0 incidents (documented in the Secure Development Policy). Emergency PRs are still tested, are logged, and receive a mandatory follow-up review within one business day.
Dependencies & supply chain
• Ruby and JavaScript dependencies are pinned via lockfiles and monitored for advisories via Dependabot / GitHub Advisory Database.
• Security-relevant dependency bumps are triaged and merged with the same review + CI gates as feature work.
• Container base images are pulled from official language registries; builds are reproducible.
Network & application security
Perimeter & DDoS mitigation
• Vercel Firewall is active on production frontends with Bot Protection, AI-bot blocking, and managed DDoS mitigation.
• CloudFront provides edge-level DDoS defense on media distributions.
• Only three surfaces accept inbound traffic — Vercel edge (frontends), Render ingress (API/admin), and CloudFront (media). Databases, cache, and workers have no public ingress.
Application security
• Cross-Site Scripting (XSS) protections via Rails’ default output escaping and Content Security Policy headers.
• Cross-Site Request Forgery (CSRF) protection on state-changing endpoints.
• SQL injection prevented via parameterized queries throughout (ActiveRecord).
• Sensitive fields (payment tokens, session tokens) are masked in logs and Sentry error reports.
• Rate limiting and abuse detection on authentication and payment endpoints.
Third-party penetration testing
EVEN engages independent third-party penetration testers annually. Findings are triaged in Vanta, remediated on defined timelines, and re-tested.
Most recent engagement: <insert year / vendor>. Executive summary available under NDA — contact security@even.biz.
Data handling & privacy
Data categories
Category
Handling
Payment data (card numbers, bank details)
Never stored by EVEN. Handled entirely by Stripe (PCI DSS Level 1).
Fan account data (email, display name, purchase history)
Encrypted at rest; access-controlled; deleted on request per GDPR/CCPA.
Artist content (unreleased music, videos, artwork)
S3 with signed URLs; Mux streaming with signed playback; not indexed by search engines pre-release.
Communication content (fan-chat messages, comments)
Encrypted in transit via Stream Chat; moderation controls available to artists.
Analytics events (PostHog events, aggregate metrics)
Pseudonymized where possible; retention aligned to product need.
Data subject rights
• Fans and artists can request data access, correction, portability, or deletion via privacy@even.biz.
• Requests are honored within the timeframes required by applicable regulation (30 days GDPR, 45 days CCPA).
• Data deletion cascades through the application database and, where feasible, downstream processors.
Sub-processors
EVEN uses trusted sub-processors for hosting, payments, communications, and analytics. A current sub-processor register is available on request and is updated whenever a new processor is added.
Incident response
EVEN operates a documented incident response process aligned with the NIST framework (identify → protect → detect → respond → recover).
Detection & alerting
• Sentry: real-time error tracking for API, admin, and worker processes with paging on new error groups.
• Datadog / Grafana: latency, throughput, and infrastructure health with alerting on SLO breaches.
• PostHog: product-level anomaly signals (unexpected drops in auth, purchase, or release funnels).
• CloudWatch and AWS CloudTrail: audit logs for infrastructure access and configuration changes.
Response
• On-call engineer rotation with defined escalation paths; documented per-service runbooks.
• Dedicated #incidents Slack channel; incidents are declared, tracked, and postmortemed.
• Customer notification within 72 hours of confirming a personal-data breach (per GDPR Article 33).
Recovery
• Business continuity and disaster recovery plans are exercised at least annually via tabletop exercise.
• Backups: PlanetScale automated daily backups; S3 cross-region replication.
• Rollback: each service can be independently rolled back to the previous deploy; forward-fix preferred for schema-related regressions.
Vendor risk management
Every sub-processor and critical vendor undergoes a security review before onboarding. Vendors with access to customer data, payment data, or production infrastructure are classified Critical or High and receive a SOC 2 Type II report review and, where warranted, a security questionnaire.
Highlighted vendors (all SOC 2 Type II certified or equivalent):
• Hosting & data: Render, PlanetScale, AWS, Vercel
• Payments: Stripe (PCI DSS Level 1)
• Communications: Twilio, Resend, Stream Chat
• Media: Mux, Transloadit
• Auth: Magic (passwordless)
• Observability: Sentry, Datadog, PostHog
• Identity & devices: JumpCloud (SSO + MDM)
Reporting security issues
EVEN welcomes reports from the security community. If you believe you have found a security vulnerability in an EVEN service:
• Email security@even.biz with a description, reproduction steps, and any relevant details.
• Please do not exploit the issue beyond what is necessary to demonstrate it; do not disclose it publicly until we have had a reasonable opportunity to remediate.
• We will acknowledge receipt within 3 business days and provide a resolution timeline once we have triaged.
We do not currently operate a paid bug-bounty program, but we will publicly acknowledge coordinated disclosures upon request.
Contact
General security:
Privacy & data subject requests:
Compliance / audit inquiries:
Trust materials (SOC 2, DPA):
