swissplanif/

Security · public doc

So a DPO reads it on a Friday.

Not a marketing checkbox. Every layer is documented, tested, and designed on the assumption that a regulator, a customer or an auditor will ask.

See pricingRequest a VAPT
CH
sovereignty by default
verifiable strict mode
10 years
append-only audit
edits rejected by the database · trigger
0
queries without isolation
PostgreSQL RLS per tenant
4
interface languages
FR · DE · IT · EN

06 layers

Every link documented. Every key turned.

We don’t sell a padlock. We sell a cockpit that is auditable end to end.

01 · layer

Tenant isolation enforced by the database.

PostgreSQL Row-Level Security is enabled on every table. Application code never writes a WHERE tenantId — Prisma sets a session GUC that the policy reads. A bug that forgets to scope returns zero rows, never another tenant’s data.

  • Postgres RLS enforced · a per-tenant policy on every tenanted table
  • UUID v7 everywhere · no sequential increment
  • Non-superuser application role — the database refuses the bypass even if the code has a bug
  • Two-tenant isolation tests, run against a real database under the application role
layer 01

illustration of the principle

02 · layer

Swiss sovereignty, verifiable in the code.

Core infrastructure at Infomaniak — datacentres in Switzerland. Strict Swiss sovereignty mode disables every feature that requires processing outside Switzerland — a rule enforced in the backend, not an interface setting. The flows that remain are disclosed: Stripe billing (Ireland), minimised push notifications. The sub-processor register is public.

  • Postgres, Redis, S3 (MinIO) · Swiss core infrastructure (Infomaniak)
  • Strict mode: all processing outside Switzerland disabled, checked by the backend
  • Sovereign AI Gateway by default (Llama 3.3 via Infomaniak)
  • Frontier LLM (Anthropic — inference may run outside the EU/CH, covered by standard contractual clauses and the Data Privacy Framework), on explicit opt-in only
layer 02

illustration of the principle

03 · layer

Secrets outside the code, never in the repository.

Secrets do not live in the code: the keys come from the server environment, reachable only by the system administrator. Sensitive secrets stored in the database (TOTP, webhook signing) are envelope-encrypted. Automated rotation and automated secret scanning arrive with a dedicated secrets manager.

  • Secrets in server environment variables · outside the repository
  • HTTPS everywhere (Let’s Encrypt, HSTS)
  • In-house authentication · Argon2id, TOTP MFA available
  • Stripe webhooks · HMAC verification on the raw body
layer 03

illustration of the principle

04 · layer

Native compliance: nLPD, GDPR.

Not a cosmetic checkbox. Every AI decision is traced (model, input, output, score, alternatives). The audit log is append-only — enforced by a PostgreSQL trigger — kept for 10 years, viewable in the app and exportable (JSON) at the request of the DPO or an inspector.

  • GDPR right to erasure in tenant self-service (cascading DELETE)
  • AI decisions logged: model, inputs, outputs, alternatives
  • PII pseudonymisation in all Pino logs
  • Strict CSP + helmet headers on the NestJS API
layer 04

illustration of the principle

05 · layer

Audit log append-only, 10 years.

Every business mutation is logged: who, what, when, from which IP, with what outcome. The database rejects any edit to an entry (PostgreSQL trigger). Deletion is open only through two declared paths: the statutory retention purge and the full erasure of a tenant at its own request.

  • Edits (UPDATE) always rejected by a PostgreSQL trigger
  • Viewable in-app · exportable via API (JSON)
  • 10-year retention · aligned with statutory bookkeeping retention (CO)
  • Versioned schema — no breaking change on historical rows
layer 05

illustration of the principle

06 · layer

Backups and recovery, without over-promising.

Restore procedures are documented in runbooks versioned alongside the code. The off-site backup programme and the quantified commitments (RPO/RTO) are being put in place — we present them as work in progress, not as done.

  • Restore runbooks versioned alongside the code
  • Data on Swiss Infomaniak infrastructure
  • Contractual RPO/RTO: introduced with the Moyenne and Grande plans
  • The real state of the setup is shared on request — no embellishment
layer 06

illustration of the principle

Compliance roadmap

What is in place. What is coming.

In production

nLPD · GDPR practices

Target Q4 2026

Full security dossier, shared on request

Target 2027

Encrypted backups off the production machine

Target 2027

Self-service audit log export

Ask your questions.

Security dossier, architecture, sub-processor register, DPIA — shared on request, from the first conversation.

Email security@See the product
Sécurité — SwissPlanif · SwissPlanif