# Security & Data Handling

How Monad protects your data in transit and at rest, how it handles and retains that data, and where to manage access.

## Encryption in transit

All traffic to and from Monad is encrypted with TLS. This covers push inputs (HTTP, OTLP, Splunk HEC, syslog), pull connections to your sources, and delivery to your output destinations. In self-managed deployments you provide the TLS certificates that terminate traffic at the gateway and HTTP input — see [Customer Helm Install](/docs/guides/customer_helm_install).

## Encryption at rest

Sensitive data that Monad stores is encrypted at rest using **AES-256-GCM**, with an envelope-encryption model:

- Each Monad organization is issued its own **Data Encryption Key (DEK)**.
- Every DEK is wrapped by a **Key Encryption Key (KEK)** before it is stored; unwrapping a DEK requires the KEK.

Who holds the KEK depends on how Monad is deployed:

- **Monad Cloud (SaaS):** Monad manages the KEK on your behalf.
- **Self-managed (Helm):** you supply and are the sole custodian of the KEK, which never leaves your cluster. Enable key encryption and provide the key material as described in [Customer Helm Install](/docs/guides/customer_helm_install).

## Tenant isolation

Monad Cloud is a multi-tenant service in which each customer's data is **logically isolated**:

- **The organization is the tenant boundary.** Your inputs, outputs, transforms, enrichments, pipelines, secrets, and data are scoped to your Monad organization. Users, roles, and API keys are organization-scoped as well — a credential issued for one organization cannot read or act on another organization's resources.
- **Cryptographic separation at rest.** Each organization is issued its own Data Encryption Key (see [Encryption at rest](#encryption-at-rest)), so each tenant's data at rest is protected under a distinct key.
- **Enforced on every request.** Access is checked against [organization RBAC](/docs/guides/organization-rbac) for each API and UI operation, so the isolation boundary holds consistently across the platform.

## Data handling & retention

Monad is a **streaming pipeline, not a data store.** Records are ingested, transformed, and routed to your destinations in-stream:

- Monad does **not** maintain a long-term datastore of your event data. In-flight records are held only transiently — buffered for reliability while they move through the pipeline (see [Reliability & Delivery](/docs/guides/reliability)) — and are not retained after delivery.
- Routing is **storage- and vendor-neutral**: your data is delivered only to the [outputs](/docs/outputs/index) you configure. Monad does not require you to land it in a Monad-owned store, and cloning one event to multiple destinations does not create a Monad-side copy of that data.

## Access control & auditing

- **Role-based access control (RBAC).** Scope what each user can view, create, modify, or delete with default or custom roles — see [Organization RBAC](/docs/guides/organization-rbac).
- **Single sign-on (SSO).** Connect your identity provider for centralized authentication — see [SSO](/docs/sso/index).
- **API keys.** Issue scoped keys for programmatic access — see [API Keys](/docs/guides/api-keys).
- **Audit logs.** Administrative and configuration actions are recorded and retrievable through the Monad API — see the [Audit Logs API](/docs/api/audit-logs).

## Compliance

Monad undergoes an independent **SOC 2 Type II** examination on an annual basis, covering the security, availability, and confidentiality of the platform.

The current SOC 2 report, along with Monad's other security documentation and certifications, is available through the [Monad Trust Center](https://trust.monad.com). Reports are released to customers and prospects under NDA — request access from the Trust Center.