Security

How Nisium protects tenant data with EU hosting, tenant isolation, evidence integrity, and defense-in-depth controls.

Last updated: June 2, 2026 · Version 1.0

Nisium is built for regulated operators: EU hosting targets, tenant isolation, evidence integrity hashing, and audit trails. This page describes our security model — not marketing slogans.

Nisium is a multi-tenant NIS2 compliance platform. We combine application security, cloud infrastructure controls, and operational practices so customers can manage incidents, evidence, and vendor risk with confidence.

This page summarizes our security model. For personal data handling, see our Privacy Policy.

Architecture overview

  • Region: Production data is hosted in AWS eu-central-1 (Frankfurt) with an EU data residency target.
  • Application: Next.js frontend and FastAPI API with PostgreSQL (RDS) and object storage (S3) for evidence files.
  • Identity: Amazon Cognito for tenant users (password + TOTP MFA; SAML federation for essential entities where configured).
  • Vendor access: Time-limited magic links and OTP — vendors do not receive standing Cognito accounts.

Tenant isolation

  • Row-level security (RLS) in PostgreSQL enforces tenant boundaries using session context (`tenant_id`, `user_id`, `role`).
  • Role-based access control limits features by role (e.g. compliance manager, security analyst, executive, auditor).
  • Cross-tenant access is denied by design at the data layer.

Authentication and access

  • Cognito password policy and TOTP MFA (per platform defaults).
  • Optional SAML 2.0 SSO for essential entities.
  • JWT claims include organization context for backend authorization.
  • Append-only audit trail for security-relevant actions.

Evidence integrity

  • Evidence versions include SHA-256 integrity hashes.
  • Metadata, retention policies, and legal hold support audit and litigation workflows.
  • Files are stored in encrypted object storage (KMS).

Data protection

  • Encryption in transit (TLS) and encryption at rest (KMS for RDS and S3).
  • Secrets managed via AWS Secrets Manager in production deployments.
  • AI features (where enabled) minimize and mask PII before content is sent to external model providers.

Vendor portal security

  • Magic links use signed JWTs (RS256) with short expiry and limited use.
  • Optional OTP at submission.
  • Vendor view-access grants default to short expiry windows (least privilege).

Operational security

  • Vulnerability management and dependency scanning in CI (e.g. container image scans).
  • Logging and monitoring via cloud observability (e.g. CloudWatch).
  • Incident response procedures for platform operations.

Responsible disclosure

Report suspected vulnerabilities to support@nisium.com with enough detail to reproduce. We aim to acknowledge reports promptly and coordinate remediation.

Related documents

This document is effective as of June 2, 2026. Material changes will be posted on this page.