Security

Single-tenant.
By design.

Every insigz customer runs in their own database, their own service account, their own Cloud Run instance. There are zero cross-tenant query paths in production. Multi-tenant isolation is enforced at the infrastructure layer, not at the application layer.

RESIDENCYCH or your region
ENCRYPTIONTLS 1.3 / AES-256
UPTIMECustom SLA
POSTUREDefense-in-depth
01 / POSTURE

Three things, deliberately.

Most "enterprise security" pages list 40 features. We list three things we organize the whole company around.

/01 ISOLATION

Single-tenant from day one.

Every customer gets their own database, their own KMS keys, their own Cloud Run service. No shared pool, no multi-tenant escape hatches.

  • Dedicated Postgres instance
  • Dedicated VPC + service account
  • Dedicated KMS key (or BYOK)
  • Zero cross-tenant query paths
/02 PROVENANCE

Every claim cites its source.

Append-only audit logs. Per-claim provenance from observation to report. If a regulator asks "where did this number come from?", we trace it back through events to signed source observations.

  • Signed source observations
  • Append-only audit logs
  • Per-claim citation chains
  • Exportable trace, machine-readable
/03 RESIDENCY

Switzerland by default. Your region on request.

Customer data lives in Switzerland (zone europe-west6, Zürich) by default — or in whatever region you require, anywhere in the world. No mandatory US transit, no middleboxes you didn't approve, no Microsoft Graph paths touching customer data.

  • GCP Switzerland (Zürich)
  • EU sub-processors only
  • No US legal exposure on customer data
  • Self-hosted option for higher tiers
02 / IN DEPTH

How it actually works.

The detail that matters when your security team reviews us. Written for technical readers; we'll happily walk you through any of it on a call.

ARCHITECTURE

Tenant isolation, infrastructure-layer.

Every customer engagement runs in a single-tenant Postgres database with its own VPC, its own Cloud Run service account, and its own KMS keys. Tenant boundaries are enforced by infrastructure controls — IAM policies, network ACLs, KMS scoping — not by application-layer string comparisons.

This is more expensive than multi-tenant SaaS economics. We accept that cost because it's the only way the trust position holds.

ENCRYPTION

TLS 1.3 in transit. AES-256 at rest. BYOK supported.

In transit: TLS 1.3 only. HSTS preload, certificate pinning available on dedicated subdomains. Internal service-to-service traffic uses mTLS with rotated certificates.

At rest: AES-256 via Cloud KMS. Each tenant gets its own KMS key — we can't decrypt their data with our root credentials. Customers on Pro/Enterprise tiers can bring their own KMS key (BYOK).

Backups: Same KMS key as the primary database. Point-in-time recovery for the past 35 days; backups encrypted, region-locked.

AUTHENTICATION

OIDC, MFA, row-level security.

OIDC integration with your identity provider (Okta, Microsoft Entra, Google Workspace, generic OIDC). MFA enforced for all roles. No password storage on our side; we never see credentials.

Authorization is enforced at the database via Postgres row-level security. Each role's visibility scope is a policy in Postgres, not a check in application code — bypassing the application layer (which we'd notice) still doesn't bypass authorization.

AUDIT

Every action, every inference, every decision — logged.

Every read, write, agent inference, and approval is recorded with timestamp, user, action, payload hash, and provenance chain. Logs are append-only and signed; tampering produces a verifiable integrity break.

Retention: engagement duration + 12 months minimum. Exports: machine-readable JSON or CSV on request. We don't sell or share audit logs; they're for you and your regulators only.

VULNERABILITY MGMT

Tested, watched, disclosed.

  • Quarterly third-party penetration test (latest: 14.03.2026, no critical findings — report available under NDA)
  • Weekly automated dependency scans (Snyk + Dependabot)
  • Responsible-disclosure program: security@insigz.com · 30-day acknowledgment SLA
  • Confirmed-incident customer notification within 72 hours
SUB-PROCESSORS

A small, audited list.

We list every sub-processor publicly at /legal#subprocessors. New sub-processors are announced at least 30 days before they go live. Customers receive email notice; right of objection per DPA.

03 / CERTIFICATIONS

Where we are.

An honest snapshot. Where we have certifications, we say so. Where we don't yet, we say so. We don't claim what we don't have.

● COMPLIANT
GDPR + Swiss FADP
CURRENT · ANNUAL REVIEW
◐ IN PROGRESS
ISO 27001
AUDIT SCHEDULED Q3 2027
○ PLANNED
SOC 2 Type II
Q4 2026 · Q1 2027 REPORT
● ATTESTED
Penetration tested
14.03.2026 · QUARTERLY
04 / ACCESSIBILITY

Where we stand on a11y.

Stated up front. The platform serves analysts in regulated sectors; accessibility is a procurement requirement, not a nice-to-have.

CONFORMANCE TARGET
WCAG 2.1 AA · EN 301 549

Tracked product-wide. Public VPAT (Voluntary Product Accessibility Template) available on request under NDA.

CURRENT POSTURE
  • Color contrast: 4.5:1 body / 3:1 large text · verified in both themes
  • Keyboard navigation: full coverage on chat, tables, nav, dialogs
  • Focus rings: 2px signal-green, 3:1 against every surface
  • Screen reader: aria-live on chat streaming, table semantics on Bloomberg-grade lists
  • Reduced motion: all animations honor prefers-reduced-motion
  • Touch targets: 44×44 minimum on coarse pointers
Mobile strategy: insigz on a phone is read + act-on-alert, not author. You can read notifications, review case summaries, view an entity, and approve/reject a pending item. The full map workspace, scenario authoring, and report drafting are desktop-only by design.
SECURITY REVIEW

Need our SIG, our pen-test report, or a security questionnaire response?

security@insigz.com →