Skip to main content

Data Protection

This page describes how customer data is protected at rest, in transit, and between Breeze components.

Encryption in transit​

All external connections to Breeze use HTTPS with TLS 1.2 or higher. This includes:

  • Browser-to-frontend traffic (Vercel-managed certificates).
  • Browser-to-backend API traffic.
  • Backend-to-database traffic (MongoDB driver enforces TLS to Atlas).
  • Backend-to-Azure-Blob-Storage traffic.
  • All outbound integrations (email provider, eID providers, partner APIs).

Authentication cookies are issued with the httpOnly, Secure, and SameSite attributes set to protect against client-side tampering and cross-site request forgery.

Encryption at rest​

Storage layerMechanism
MongoDB AtlasAES-256, integrated with the cloud provider's KMS. Backups and snapshots inherit the same encryption.
Azure Blob StorageAES-256 (Azure Storage Service Encryption, enabled by default).
Atlas backups & snapshotsEncrypted at rest with the same key material as the primary cluster.

Field-level encryption for sensitive values​

In addition to storage-layer encryption, certain highly sensitive values — including multi-factor authentication codes — are encrypted at the application layer using AES-256 with a per-message random initialization vector. The encryption key is supplied via environment configuration and supports versioning, which allows the encryption key to be rotated without downtime or re-encryption of existing records.

Sensitive data fields (tenant-controlled)​

Tenant administrators can mark any field in a credential template as a sensitive data field. The Breeze platform then applies the following protections to data stored in that field automatically:

  • Encrypted at rest at the application layer. Values are AES-encrypted before being written to the database. The plaintext never reaches MongoDB. If encryption fails for any reason, the write is aborted rather than fall back to plaintext.
  • Masked on display for users without privileged access. Users who can see that a record exists but who lack the role to view its sensitive contents see a mask (******) instead of the value. Tenant administrators can also configure partial-reveal patterns — for example "show only last four characters" — for fields where users need to recognize but not read the full value.
  • Redacted from audit logs. When an audit event captures the before/after state of a record, the value of any sensitive field is replaced with [REDACTED] before the audit event is written. This keeps the audit log itself free of the sensitive payload, so the audit log can be retained, exported, and shared without re-exposing the protected data.
  • Failure-safe on read. If decryption fails (for example, because the encryption key is unavailable), the value is masked rather than returned as ciphertext.

This control is intended for fields that contain national identity numbers, identity-document numbers, or any other value the tenant determines requires application-layer protection beyond standard at-rest encryption. The tenant retains control of which fields are marked sensitive; Breeze provides the implementation.

Password hashing​

User passwords are never stored in plaintext. Breeze uses bcrypt (10 rounds) to hash all user passwords on creation, password reset, and credential activation. Plaintext passwords are stripped from API responses and from log output.

PII minimization in logs​

Application logs and error reports are designed to avoid recording personal data:

  • Email addresses are masked or omitted before being sent to the error-monitoring service.
  • Authentication tokens, password material, and MFA codes are never logged.
  • Stack traces are captured but inspected for redaction of identifying values where possible.

Data residency​

All primary customer data — the operational MongoDB Atlas cluster, Azure Blob Storage, the application servers, the workflow orchestrator, and the cache layer — is hosted in Norway (Microsoft Azure Norway East). Backups are stored in the same region. There is no cross-border transfer of customer data for primary processing.

A small number of operational sub-processors (for example, the transactional email provider and error-monitoring service) operate inside the EU/EEA. See Sub-processors for the full list.

Backups​

The MongoDB Atlas cluster is configured with continuous backup and point-in-time restore. Backups are encrypted at rest and stored in the same region as the primary cluster. The current retention policy is:

  • Point-in-time restore window — 5 days.
  • Hourly snapshots — taken every 6 hours, retained for 5 days.
  • Daily snapshots — retained for 1 week.
  • Weekly snapshots — retained for 4 weeks.
  • Monthly snapshots — retained for 6 months.

Data deletion​

When a tenant administrator deletes a user, credential, or other record through the Breeze admin UI, the record is removed from the operational database. Backups continue to retain the record until the backup retention window expires.

For data subject erasure requests under GDPR Article 17, the responsible tenant administrator can use the in-product tools to delete or anonymize records. See Compliance and data protection for the full data-subject-rights process.