Boring infrastructure choices, made on purpose.

1. Infrastructure

• Database. Supabase Pro, running PostgreSQL 17 in the US-East-1 region. We do not replicate member data outside the United States.
• Application runtime.Vercel Pro, using Fluid Compute for serverless execution and edge delivery. Static assets are served from Vercel's global CDN.
• Compliance pedigree of providers. Both Supabase and Vercel maintain SOC 2 Type II reports, available on request through their security pages.
• Isolation. Production, staging, and development environments are physically separate Supabase projects with no shared credentials.

2. Network and transport

• TLS 1.3 everywhere. Every connection between your browser, the Vercel edge, the Supabase database, and every third-party service we call on your behalf is encrypted in transit with TLS 1.3.
• HSTS preloaded. The discipleiq.com domain is on the HSTS preload list, forcing HTTPS for every visitor before any HTTP traffic can be intercepted.
• Content Security Policy. We ship a strict CSP that blocks inline scripts from any origin we have not explicitly allowlisted, mitigating the impact of any future cross-site scripting bug.
• Security headers. X-Content-Type-Options, Referrer-Policy, and Permissions-Policy headers are set platform-wide.

3. Authentication

• Supabase Auth. User credentials are managed by Supabase Auth. Application code never sees raw passwords. Password hashes are stored using a modern, memory-hard algorithm.
• Sign-in options. Email and password, plus Google OAuth. Magic-link and additional OAuth providers are on the V2 roadmap.
• Multi-factor authentication. MFA is required for the super-admin and tenant-owner roles, with time-based one-time passcodes generated by any standard authenticator app.
• Session management. Sessions are managed through a first-party, HTTPOnly, SameSite cookie. Sessions are revoked on password change and immediately on tenant-administrator removal.

4. Authorization and tenant isolation

Tenant isolation is the single most important property of a multi-tenant discipleship platform. We treat it as a database-layer concern, not an application-layer concern.

• Row-Level Security on every tenant-scoped table.Every table that holds tenant data carries a PostgreSQL Row-Level Security policy that filters on the requesting user's tenant membership. Application code that forgets to add aWHERE tenant_id =clause cannot leak data, because the database itself refuses to return rows the policy excludes.
• No application-layer tenant filter. Because RLS is the gate, an entire class of cross-tenant data leak is structurally impossible.
• Service-role keys are server-only. The Supabase service-role key, which bypasses RLS, never appears in client-side code and is restricted to a small set of trusted server routes.
• Role hierarchy. Within a tenant, roles run from member through group leader, tenant administrator, and tenant owner. Cross-tenant super-admin access is reserved for DiscipleIQ staff and audited on every read.

5. Encryption and key management

• At rest. AES-256 for the primary database, the storage layer, and the automated backups. Encryption keys are managed by Supabase and rotated on the schedule documented in their security overview.
• At column level for secrets. Planning Center OAuth tokens are stored inside Supabase Vault, encrypted with a per-tenant key. Tokens are never returned to the application layer, never logged, and never displayed in the admin UI.
• API keys. Third-party API keys for Resend, Anthropic, OpenAI, Google, and Planning Center are stored in Vercel Sensitive environment variables, scoped to the production deployment, with read access restricted to the production runtime.

6. Auditing

Every state-changing operation, including administrative reads of tenant data by DiscipleIQ staff, is recorded in theaudit_logtable. The audit log is tenant-scoped on read, retained indefinitely, and structured for after-the-fact incident investigation. Tenant administrators can export their own audit trail at any time from the admin dashboard.

7. Backups and recovery

• Daily snapshots. The production database is snapshotted every day. Snapshots inherit the same AES-256 encryption as the primary database.
• Point-in-time recovery. We can restore the database to any moment within the previous seven days.
• Restore drills. We run a quarterly restore drill against a non-production project to validate the procedure end-to-end.

8. Logging and observability

• Application errors are captured by Sentry with a 90-day retention. We strip personally identifying fields before any exception is sent.
• API and slow-query logs live in Supabase with a 7-day retention.
• Frontend performance is measured by Vercel Analytics with a 30-day retention; we do not capture user-identifying data through this channel.
• Matching quality (accept and decline signals) and outreach events are retained in their own tables to support model quality monitoring.

9. Incident response

We commit to notifying affected tenant administrators within 24 hours of confirming a customer data breach. Notification includes a description of what we know, what we do not yet know, what we are doing about it, and what we recommend you do. We follow up with a written post-incident review within fourteen days. Our incident playbook covers triage, containment, eradication, recovery, and lessons learned.

10. Compliance posture

• SOC 2. SOC 2 Type I is in progress, with a target report date in the third quarter of 2026. SOC 2 Type II is the year-two objective.
• HIPAA. DiscipleIQ is not HIPAA-certified. The data we process is not, by default, protected health information. We operate to HIPAA-style administrative, technical, and physical safeguards so that a future HIPAA conversation is short.
• GDPR. Our customer base is United States focused. We are not subject to GDPR today. The data subject rights described in ourprivacy policy are GDPR-aligned by design so that crossing the Atlantic is a contract change, not a re-architecture.
• PCI. We never see card numbers. Stripe tokenizes payment data at the browser. Our PCI scope is the lowest possible scope under SAQ A.

11. Vulnerability management

• Penetration testing. A third-party penetration test is scheduled before public beta and will run annually thereafter. The summary report is available under non-disclosure to qualified prospects.
• Dependency monitoring. Dependencies are scanned on every pull request, and high-severity vulnerabilities block deployment.
• Patch cadence. Critical security patches are applied within 48 hours. High-severity patches are applied within seven days.

12. Responsible disclosure

We do not yet operate a paid bug bounty. We respond to good-faith vulnerability reports sent tosecurity@discipleiq.com within two business days. Researchers who follow responsible-disclosure practices, including not exfiltrating tenant data and not running disruptive tests against production, will not face legal action from DiscipleIQ for the act of reporting.

13. Contact

Security contact:security@discipleiq.com. For privacy questions, see ourprivacy policy. For contractual commitments, see ourterms of service.