Skip to content
Saiku Cloud

Security & trust posture

Enterprise procurement teams need to know where a vendor stands on security before they even look at the product. This page is the honest version — what’s already in place, what’s underway, and what we deliberately haven’t done yet. Kept current; last reviewed July 2026.

Third-party attestations

AttestationStatusNotes
SOC 2 Type ITarget Q4 2026Scoping complete; auditor selected. Pre-audit gap remediation in progress.
SOC 2 Type IITarget Q3 2027Follows Type I once the observation window is complete.
ISO 27001Not on the current roadmapReprioritise on request for large European contracts.
HIPAA BAANot offered todayWe don’t sign BAAs, and Saiku Cloud isn’t positioned for PHI. If you have a healthcare use case, talk to us before you build on it.
DPA (GDPR)On requestStandard DPA available; customer amendments considered.

We don’t publish attestations we don’t hold. If you see “SOC 2 compliant” on a vendor’s page without a report date, ask them for the report — several competitors ship the label without the paperwork.

Data handling

Where your data lives.

  • Saiku Cloud runs on European infrastructure (Scaleway, Netherlands). US regions available on request for tenants with data-residency requirements.
  • Warehouse data itself never leaves your warehouse. Saiku is a semantic layer — queries are compiled to SQL and dispatched to your database; results transit our platform to render in the UI but are not persisted server-side by default.
  • Metadata that IS stored: cube definitions, saved workbooks, query history for audit, user accounts, subscription info. All scoped per tenant (see Tenant isolation).

Encryption.

  • In transit: TLS 1.3 for all customer-facing endpoints (cloud.saiku.bi, demo.saiku.bi, api.saiku.bi). HSTS enforced with a one-year max-age.
  • At rest: database volumes encrypted at the cloud provider level (LUKS / dm-crypt equivalent). Warehouse credentials encrypted with per-tenant keys.
  • Secrets: operator secrets (API keys, DB passwords) never written to logs. See the audit log for what IS recorded.

Retention & deletion.

  • Audit events: 90 days on the default plan, up to 7 years on Enterprise.
  • Workbooks + saved queries: retained until you delete them; hard delete on account close within 30 days.
  • Query result cache: default 30 minutes, tenant-configurable.
  • Backups: nightly full + hourly incremental; retained 30 days; encrypted at rest.

Access control

  • SSO — SAML 2.0 supported on the Team plan and above. OIDC / OAuth 2.0 on the Enterprise plan.
  • MFA — enforced for the operator (root admin) account. Tenant admins can enforce for their own members.
  • Role-based access — see Members & roles. Row-level security (RLS) at the cube level ships in Saiku 4.6.
  • Session management — configurable timeout; forced re-auth after 24 hours by default.
  • Service accounts / API keys — scoped, revocable, and appear in the audit log.

Application security

  • Vulnerability scanning: every push to development runs Snyk against the dependency tree; every release runs OWASP Dependency-Check via mvn -P security verify. Findings above CVSS 7.0 block release.
  • Secrets scanning: GitHub secret scanning enabled on every branch; commit hooks reject anything matching common credential patterns.
  • CI security: builds run on ephemeral GitHub-hosted runners; no persistent secrets outside GitHub Actions secrets. Signing key for artifact publishing lives in a separate hardened environment.
  • Dependency hygiene: every dependency added to a POM runs through the Sonatype OSS Index for known vulnerabilities + malicious-package detection before merge.

Incident response

  • On-call: business-hours (UK) for Team plan; 24/7 for Enterprise.
  • Notification target: Enterprise customers notified within 24 hours of confirmed data breach; Team plan notified within 72 hours.
  • Status page: status.saiku.bi — subscribable via email or RSS.
  • Post-mortems: published for any incident lasting > 30 minutes on Enterprise plans. Redacted public post-mortems for wider incidents on the changelog.

The self-hosted story

For customers who can’t send data through any hosted platform, Saiku ships a self-hosted build under the same Apache 2.0 licence as the Cloud version. The security posture there is the operator’s responsibility, but Saiku ships with:

  • Fail-closed defaults (see the AiPolicy guard — production defaults to schema-only for AI endpoints)
  • Non-default admin credential refusal (Saiku refuses to serve in production while the shipped admin/admin credentials are unrotated)
  • Opt-in OpenTelemetry so security events flow to your existing SIEM
  • No phone-home; no telemetry off the box unless you configure it

See the self-hosting guide for hardening advice.

What we deliberately haven’t done

Transparency about the gaps is worth more than a marketing check-list.

  • FedRAMP: No plans. Not a market we serve.
  • PCI-DSS: Not certified. Saiku is a semantic-layer platform, not a payment processor — we don’t store cardholder data. If your BI use case touches cardholder data, you need a compensating control on the warehouse side.
  • GDPR data localisation for edge regions: EU-only today. Asia Pacific + US regions available on request but not the default.
  • Bug bounty: Not currently running one. Responsible disclosure handled directly via security@saiku.bi.

Contact