Trust & security

Pulsea is built in Switzerland and is designed to be compliant with both the EU General Data Protection Regulation (GDPR) and the Swiss Federal Act on Data Protection (nFADP) from day one.

The processor/controller model is explicit: the tenant — the federation or organising committee running the event — is the data controller; Pulsea acts as the data processor on their behalf.

The governing documents are published and live: Privacy Policy, Terms of Service, and Data Processing Agreement.

Data hosting locations are documented transparently and follow our published infrastructure policy.

For the exact hosting region applicable to your event, request our infrastructure policy at support@usepulsea.com.

Multi-tenancy is the platform's first non-negotiable rule: every tenant-scoped record carries an entity_id, every query filters by it, and an unauthorised cross-tenant request returns 404 — never 403, so the existence of another tenant's data is never revealed.

This is not asserted; it is what our continuous-integration suite actually proves against a real database on every change:

• A two-tenant, end-to-end lifecycle proof. A second, independent tenant is registered, pays via a signed Stripe settlement webhook, and is accredited — and every persisted row (registrations, invoices, payments, transaction logs, accreditations) is scoped to its own tenant, while the other tenant holds zero of those rows.
• A runtime badge-scanning isolation proof. One tenant's badge scanner cannot validate another tenant's accreditation — blocked whether an attacker presents a stolen token or a stolen identifier, each denied with a generic “not found” that never reveals the cross-tenant record exists.
• A read-only coverage audit. An independent audit across reporting, networking, search and cross-event memory found no exploitable cross-tenant read leak: the entity boundary is enforced in the application layer on every surface examined.

Honest scope: the platform is neutral by design and proven-isolated in CI. We state the isolation proof plainly and do not claim more than CI shows — remaining tenant-neutrality work is tracked to completion in our template-readiness programme.

No code that touches money, personal data, or security reaches production without a human reviewing and approving it. Under our automation policy, database migrations, any payment path (Stripe, invoicing, VAT, refunds), security surfaces (authentication, tokens, permissions) and credentials are never automated — they require a person to read the change and decide.

• Payments. Stripe Connect only. Every paying path uses destination charges, so funds settle directly to the federation and Pulsea never handles raw card data. Powered by Stripe.
• Access control. Roles are enforced at the API layer — never merely hidden in the interface — with database row-level security as a defence-in-depth backstop behind application-layer tenant filtering.
• Data integrity. Quota allocation, hotel inventory and invoice numbering run inside atomic transactions: no partial states, and concurrent registrations against a fixed quota can never oversell it.
• Encryption. Data is encrypted in transit (TLS) and at rest by our managed infrastructure.

For a security questionnaire, the signed Data Processing Agreement, or our infrastructure policy, contact support@usepulsea.com.

Back to Pulsea