Security

Production environment

Production runs in the EU (Frankfurt) under a dedicated, fully isolated cloud account, separate from any other product. Compute, networking, storage, secrets, and logging are all dedicated to Syncanix. EU residency is enforced in code — a misconfigured deploy refuses to run if it resolves to any region outside the EU.

Encryption

All customer data is encrypted at rest with AES-256. Every data store — databases, object storage, attached volumes, and logs — is encrypted with managed keys that rotate on a managed cadence.

All data in transit uses TLS 1.3 minimum. The marketing site, the customer dashboard at app.syncanix.com, and the API endpoint all redirect HTTP to HTTPS and enforce HSTS with a two-year max-age including subdomains, with preload. BYOK (bring-your-own-key) is supported on the enterprise tier — customer-supplied keys are used for the customer's data envelope without ever appearing in Syncanix log output.

Identity and authentication

Dashboard authentication is handled by Auth0. Every API endpoint is guarded by an auth layer that validates the JWT signature against the provider's JWKS endpoint, verifies the audience and issuer, and rejects expired tokens. The guard is default-on; an endpoint is public only when explicitly marked. There is no "I forgot to add auth" failure mode — the default is enforced.

Authorisation

Permission checks live in the service layer, not at the API edge. A service that answers "edit project Y" verifies the caller has at least Editor role on project Y before touching the database. Service-to-service calls use a separate authentication scheme (signed envelopes or platform-authenticated endpoints) — never user JWTs.

IAM and least-privilege

Every workload role carries the smallest possible policy. Policies are written explicitly; no role uses broad wildcards. Where resource scoping isn't expressive enough, policies scope by tag. No long-lived access keys exist in CI — the pipeline assumes a role via OIDC; local development uses short-lived credentials.

Application security

Every API argument and request body is parsed through a strict schema before reaching service code. Database queries are fully parameterised — no string interpolation of user input. Writes use typed APIs, never raw expressions built from user input.

HTTP security headers ship on every customer-facing response:

• Content-Security-Policy with a strict allowlist (Auth0, own origin, no inline scripts).
• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload.
• X-Frame-Options: DENY (clickjacking protection).
• X-Content-Type-Options: nosniff.
• Referrer-Policy: strict-origin-when-cross-origin.
• Permissions-Policy: geolocation, microphone, and camera all denied by default.

CORS is enforced at two independent layers, each with an explicit origin allowlist. A wildcard origin is rejected at build time — a production deploy without explicit origins cannot proceed.

Secrets management

Production secrets live in a dedicated secrets manager under a per-environment namespace. Non-secret configuration lives in a separate parameter store. Secrets are surfaced to workloads at boot — they never live in source control. Database credentials are rotated automatically; third-party tokens (Stripe, Anthropic, OpenAI) rotate manually on a quarterly cadence.

Logging and audit

Logs are structured JSON with 14-day retention by default. Every log line carries a correlation ID (request ID) so a single user's flow can be reconstructed end-to-end. A redact list masks token / password / secret / authorization fields automatically; full PII never lands in the logger. Authentication failures emit a WARN line with the source IP and reason — never with token contents.

Dependency hygiene

Automated dependency audits run in CI; high or critical advisories fail the build. Renovate and Dependabot are enabled on the dependency manifest and lockfile. Every new OSS library goes through a documented pre-adoption review (security, maintenance, license, lock-in, performance).

Certifications and audits

SOC 2 Type I evidence collection begins via Vanta in the month after Syncanix launches commercially, with a Type I report targeted for Q3 2026. SOC 2 Type II follows at ~9 months. ISO 27001 evidence is collected concurrently (70-80% control overlap with SOC 2) — certification targeted for Q4 2026. Full compliance status →

Incident response

Vulnerability disclosure goes to admin@syncanix.com — acknowledged within 24 hours and triaged within 72 hours. Confirmed customer-impact breaches are notified to affected customers within 24 hours of confirmation in line with the DPA's Article 33 commitment. A documented incident-response runbook is rehearsed quarterly.