How Plomo Encrypts Deal Data at Rest and in Transit

Encryption in Plomo is designed around a simple principle: data from one deal should be cryptographically inaccessible to anyone working on a different deal, even if something goes wrong at the application layer. Plomo achieves this through per-deal envelope encryption — every deal gets its own data-encryption key, and that key is managed by a cloud key management service rather than stored alongside the data it protects.

​

Per-Deal Encryption Keys

When you create a deal in Plomo, the platform generates a unique data-encryption key (DEK) for that deal. This key is used to encrypt and decrypt deal content throughout its lifecycle. The DEK itself is wrapped (encrypted) by a key-encryption key (KEK) managed in a cloud-hosted key management service. This envelope encryption pattern means:

• The raw DEK is never stored persistently — only the KMS-wrapped form is persisted
• The DEK is unwrapped only briefly, inside the backend, for authorized workflows
• Compromising the application database does not expose plaintext deal content without also compromising the KMS key

​

What Is Encrypted Per Deal

The following content fields are encrypted at rest using the deal’s data-encryption key:

​

Encrypted Document Storage

Uploaded documents benefit from two independent encryption layers:

1. Plomo application encryption — the document blob is encrypted with the deal’s DEK before being written to storage
2. Cloud storage encryption — the underlying cloud storage bucket applies its own server-side encryption on top

This means a document at rest is encrypted twice: once by Plomo (deal-scoped) and once by the storage provider (infrastructure-level).

​

What Is NOT Encrypted

Some operational fields are stored in plaintext because the product needs them to function correctly — queries, indexes, and status checks depend on these values being readable without decrypting the full deal:

• Opaque internal IDs
• Status fields (e.g., processing, complete, error)
• Timestamps
• MIME type and file size
• Category labels assigned to documents

These fields contain no customer content — they are structural metadata used to route and display information in the UI.

​

In Transit

All traffic between your browser and Plomo is encrypted in transit:

• Edge layer: HTTP/3 (QUIC + TLS 1.3) via the Cloudflare edge network — the connection from your browser to Cloudflare uses the latest transport security
• Origin layer: HTTP/2 with TLS from Cloudflare to Plomo’s backend — traffic never travels over the public internet in plaintext

​

Enterprise: Bring Your Own Key (BYOK)

Enterprise customers can supply a customer-managed key as the wrapping key (KEK) in the envelope encryption scheme. Under BYOK, Plomo’s managed key service is configured to use your key rather than a Plomo-managed key to wrap the deal DEKs. This gives your organization a cryptographic off switch: if you revoke or disable your wrapping key, the deal DEKs cannot be unwrapped, and all encrypted deal data becomes unreadable — even to Plomo’s infrastructure. This is useful for contractual off-boarding, regulatory holds, or situations where you need a guaranteed termination mechanism. To enable BYOK for your organization, contact [email protected].