Security Overview

1. Architecture and tenancy

• Multi-tenant SaaS hosted on Amazon Web Services in eu-central-1 (Frankfurt) using Dockerized application, database, search/index, and nginx services.
• Tenant isolation is enforced by Postgres row-level security, in addition to application-layer scoping. Every tenant-scoped table has a tenant_isolation RLS policy installed by migration 20260415_1300-enable_tenant_row_level_security. The database physically rejects cross-tenant reads and writes.
• Tenant identity is embedded in the JWT issued at sign-in; each database session executes against the requesting tenant's company_id.

2. Network and infrastructure

• TLS for all client-to-server and server-to-server traffic.
• HSTS enabled on production hostnames.
• Docker bridge networking between application tier, database, and search/index tier; public ingress terminates at nginx.
• Infrastructure provisioned via Ansible-managed configuration; immutable Docker-based production deploys.

3. Access control

• Spinal employee access to production requires authentication via the configured identity provider with MFA.
• Customer end-user access is via Google, Microsoft, or GitHub OAuth, or email/password with salted hash. MFA on those accounts is the responsibility of the corresponding provider/customer.
• Tenant-scoped ID lookups go through a helper that enforces company_id; a CI guard blocks regressions.

4. Data protection

• Application secrets stored by customers are encrypted before database persistence. Infrastructure-level disk, snapshot, and backup encryption are controlled by the AWS deployment configuration in eu-central-1.
• Reversible secrets stored in Spinal — integration API keys, OAuth tokens, and customer-supplied model API keys — are encrypted using a dedicated helper before persistence.
• Server-side PII redaction before submission to the LLM provider is enabled in the launch deployment. A default category set and customer-configurable regex patterns are stripped from prompts. Customers manage custom patterns at Settings → Privacy.
• Application data is stored on deployment volumes; backup and snapshot policy is configured outside the application.
• On account closure, Customer Data is deleted within 30 days unless legally required to retain.

5. AI processing

• Workspace administrators provide their own Anthropic / Claude API key and choose the Claude model at Settings → Model.
• Customer-supplied model API keys are stored encrypted in the workspace secret store and are not displayed back to users.
• Model-provider processing, retention, model-training, and transfer terms are governed by the customer's own Anthropic agreement unless an Order Form expressly states that Spinal supplies managed model access.
• Spinal does not perform automated decision-making with legal or similarly significant effects on individuals.

6. Application security

• Tenant-isolation tests in CI cover both the row-level-security policies and the no-raw-session.get rule for tenant-scoped models.
• Production secrets are loaded from environment variables and managed outside the source tree. Production startup rejects the development-default JWT and secret-encryption keys.
• Coordinated disclosure: report vulnerabilities to security@getspinal.com. We aim to acknowledge within 2 business days.

7. Incident response

Documented breach-notification process: customer notification of confirmed Personal Data Breaches within 72 hours per § 9 of the DPA.

8. Compliance posture

• GDPR. The Service is operated as a processor under Art. 28 for Customer Data containing personal data; see the DPA.
• EU AI Act. Spinal monitors developments and will adapt its disclosures and risk classification as features mature.
• Third-party certifications. Spinal does not currently hold SOC 2, ISO 27001, or comparable third-party security certifications. We will publish attestations on this page if and when they are obtained.

9. Not currently in place

To be honest with prospects, the following are not in place at Spinal as of the date above. We will update this page when each is implemented and evidenced.

• 24/7 staffed operations centre / on-call rotation
• Formal quarterly access-review process
• Annual third-party penetration test
• Formal annual security-training programme
• Formal background-check policy
• Documented disaster-recovery test cadence
• Public bug-bounty programme
• Third-party error-monitoring sub-processor (Spinal's own application logs are stored on Spinal-managed infrastructure)

10. Reporting a vulnerability

Email security@getspinal.com with reproduction steps. We will acknowledge within 2 business days, keep you informed of remediation timelines, and credit you on a hall-of-fame page if you wish (no monetary bounty programme at this time).

11. Related documents

• Data Processing Addendum (DPA) — Art. 28 processor terms, including technical and organisational measures in Annex II and breach-notification process.
• Sub-processors — Current list of authorised sub-processors with purpose, region, and notification policy for changes.
• Acceptable Use Policy — Restrictions on how the Service may be used, including prohibited content and conduct.