Security Questionnaire

Pre-filled answers for vendor security reviews. Plain-text version on request.

Request custom answers

Brainboot Security Questionnaire Pack

Pre-filled CAIQ-Lite + SIG-Lite + common vendor security questions. Version 1.0 — 2026-05-16

This document answers the questions mid-market and enterprise security reviewers ask before signing a Brainboot DPA. Public so prospects can self-serve; signed copies of any individual section available on request to security@brainboot.dev.

For our full trust page see /security. For our DPA see /legal/dpa. For subprocessors see /subprocessors.

1. Company and Governance

1.1 Legal entity name. Brainboot is the trade name; legal entity details available under NDA via security@brainboot.dev.

1.2 Years in operation. Brainboot platform launched May 2026. Founded 2026.

1.3 Number of employees with access to Customer Data. Fewer than 5. All under written confidentiality obligations.

1.4 Information security policy. Yes; maintained internally, summarized at /security. Reviewed annually.

1.5 Designated security officer. Yes; reachable at security@brainboot.dev.

1.6 Cyber insurance. Not currently held. On roadmap; available on request prior to enterprise contracts > $50K ACV.

2. Identity and Access Management (IAM)

2.1 MFA enforced for production access. Yes, for all personnel.

2.2 SSO available for customers. Yes. SAML 2.0 and OIDC supported per-org. Configure at /settings/sso.

2.3 Role-based access control. Yes. Per-org roles: owner, admin, member, viewer. See /security and DPA Annex II.

2.4 SCIM provisioning. Not yet. On roadmap; available Q3 2026 or earlier upon enterprise customer demand.

2.5 Password policy. Supabase Auth defaults: minimum 8 chars, no recently breached passwords (HIBP-checked). Customers may enforce stricter policies via SSO IdP.

2.6 Session timeout / inactivity. Default 1 hour; configurable per-org via session_keepalive proxy (see proxy.ts).

2.7 Admin actions audited. Yes. All privileged actions logged to admin_actions table (immutable append-only). Customer-exportable via /api/org/audit-log.

3. Data Protection and Encryption

3.1 Encryption in transit. TLS 1.2+ enforced on all customer-facing endpoints. HSTS enabled. Internal service-to-service over TLS.

3.2 Encryption at rest. AES-256 via Supabase-managed AWS RDS. Application-level encryption (AES-256-GCM) for SSO OIDC client secrets and similar high-sensitivity fields.

3.3 Key management. Supabase manages database encryption keys; AWS KMS underneath. Application-level keys (SSO_SECRET_KEY) rotated via env var; rotation procedure documented internally.

3.4 Customer-managed encryption keys (BYOK / CMEK). Not yet supported. On enterprise roadmap.

3.5 Data residency. Currently us-east-1 (AWS) via Supabase. EU residency on roadmap. Contact us for specific residency requirements before signing.

3.6 Tenant isolation. Row-level security (RLS) enforced on all multi-tenant Supabase tables. Service-role access limited to backend operations.

3.7 Data classification. Customer Data treated as Confidential by default. Special Category Personal Data (GDPR Art. 9) requires separate written agreement.

4. Infrastructure and Network Security

4.1 Hosting provider. Vercel (application), Supabase (database, auth, storage), Upstash (Redis rate limiting), Resend (transactional email), Sentry (errors). All listed at /subprocessors.

4.2 Firewalls / WAF. Vercel-managed edge WAF for the application; Supabase-managed for the database tier (network ACLs).

4.3 DDoS protection. Vercel-managed edge.

4.4 Vulnerability scanning. npm audit + GitHub Dependabot on every push to main. Critical advisories triaged within 24 business hours.

4.5 Penetration test. No third-party penetration test conducted to date. Will be completed before any enterprise contract > $100K ACV or earlier upon customer demand.

4.6 Bug bounty. Not yet. Roadmap.

4.7 Network segmentation. Customer environments are logically segmented via RLS, not physically separate VPCs. Single-tenant deployment available on request.

5. Application Security

5.1 SDLC. Code review required on all merges. Tests required for plan-tier gating, webhook critical invariants, usage atomicity, and rotation discipline (see vitest suite, 40+ tests as of 2026-05-16).

5.2 Dependencies. Reviewed via npm audit and Dependabot.

5.3 Static analysis. TypeScript strict mode; ESLint with security plugin.

5.4 OWASP Top 10 coverage. See /security for the controls-against-each-OWASP-item matrix. Webhook signature verification, rate limiting, RLS, and CSRF-resistant POST handlers cover the most common.

5.5 Authentication mechanisms. Supabase Auth (email/password, magic link, OAuth) + per-org SSO (SAML/OIDC) + bb_live_* API keys with constant-time hash comparison.

5.6 Webhook signature. Inbound (Stripe): signature + idempotency table. Outbound: HMAC-SHA256 with timestamp replay protection (X-Brainboot-Signature header).

6. Incident Response

6.1 Documented incident response process. Yes. Internal runbook; public-facing summary at /security.

6.2 Notification SLA. 72 hours from confirmed breach to affected Customer notification, per DPA §6.

6.3 Status page. /status, with active and recent incident history.

6.4 24/7 contact. security@brainboot.dev (monitored business hours US Eastern + on-call rotation for severity ≥ major).

6.5 Post-incident review. Public RCA published for any incident of severity ≥ major affecting customer data or availability > 4 hours.

7. Business Continuity and Disaster Recovery

7.1 Backup frequency. Daily automated backups via Supabase (managed). Point-in-time recovery within 7-day window.

7.2 Backup encryption. AES-256 (managed by Supabase / AWS).

7.3 RTO / RPO.

  • RTO (Recovery Time Objective): 4 hours for full service restoration in regional failure.
  • RPO (Recovery Point Objective): 1 hour (point-in-time-recovery granularity).
7.4 DR testing. Annual; first test scheduled Q3 2026.

7.5 Failover region. Currently single-region (us-east-1). Multi-region failover on enterprise roadmap.

8. Compliance and Certifications

8.1 SOC 2 Type 2. Not yet completed. Will commence audit cycle upon onboarding the first enterprise customer requesting it. Estimated 6-12 month audit period.

8.2 ISO 27001. Not currently certified.

8.3 HIPAA. Brainboot is not currently HIPAA-compliant and customers should not submit Protected Health Information through the Services.

8.4 PCI-DSS. Brainboot does not store payment card data. All card processing is handled by Stripe (PCI-DSS Level 1). Brainboot is therefore out of PCI scope for cardholder data.

8.5 GDPR. Yes. See DPA and /privacy. Sub-processor list at /subprocessors. SCCs (2021/914) incorporated for EEA/UK transfers.

8.6 CCPA / CPRA. Yes. Brainboot acts as a Service Provider under CCPA terms. See /privacy.

9. Third Parties (Sub-processors)

9.1 Sub-processor list maintained. Yes, at /subprocessors. 30-day notice before adding new sub-processors per DPA §4.3.

9.2 Sub-processor agreements. All sub-processors are bound by data protection terms materially equivalent to those in our DPA.

9.3 LLM provider data handling.

  • All model calls route through Vercel AI Gateway (pass-through).
  • Underlying providers (Anthropic, OpenAI, Google, etc.) do not retain customer data for model training under their enterprise API terms.
  • Customers may restrict allowed providers via org-level policy.

10. Privacy

10.1 Privacy notice. /privacy.

10.2 Data subject rights handling. GDPR rights (access, rectification, erasure, portability, restriction, objection) fulfilled within 30 days of verified request. Contact privacy@brainboot.dev.

10.3 Data retention. See DPA §11.

  • Active customer data: term of agreement.
  • Backups: 7 days post-deletion.
  • Billing records: 7 years.
  • Audit logs: 12 months minimum.
10.4 Children's data. Services not directed at children under 16. Customers agree not to submit Personal Data of children under 16 without separate agreement.

11. Operational Maturity (transparent disclosures)

Brainboot is a small, indie-founder-led company at launch stage. The following items are honest gaps we disclose proactively for procurement risk assessment:

  • No SOC 2 audit yet. Roadmap dependent on first enterprise customer.
  • No third-party penetration test yet. Same dependency.
  • No cyber insurance yet. Same dependency.
  • Single-region deployment (us-east-1). Multi-region on roadmap.
  • Sub-processor diversity is intentionally limited at launch to reduce attack surface and procurement complexity. Vetted alternates on file.
We believe transparency about the gaps is more useful to procurement teams than ambiguous claims. We are happy to discuss compensating controls and risk-acceptance procedures specific to your environment.

12. Document Hygiene

  • This pack is updated at least quarterly or upon material change.
  • Plain-text source: legal/SECURITY-QUESTIONNAIRE.md in our repo.
  • Rendered at: /security/questionnaire.
  • Custom answers / NDA-protected items: security@brainboot.dev.

Contact

  • Security incidents and questions: security@brainboot.dev
  • Privacy / data subject rights: privacy@brainboot.dev
  • Legal / DPA execution: legal@brainboot.dev
  • Status page: /status

Plain-text source: legal/SECURITY-QUESTIONNAIRE.md. Last updated 2026-05-16.