Plain text payloads
Request messages, response text and uploaded files should be encrypted before storage, so the server handles protected payloads instead of readable documents.
Privacy
Privacy by short retention and limited access.
BurnDrop is designed to collect sensitive data only for the time needed to complete an exchange, not to create another permanent copy of client documents.
Privacy overview
What BurnDrop tries to minimize.
This page is a product-level privacy overview. A production deployment should add the final legal policy, DPA and regional notices that match the operating company.
Long document retention
BurnDrop is meant for exchange. Documents should be downloaded or exported to the customer system, then removed according to retention policy.
Unclear access
Workspace scoping, ownership, approvals and audit events help keep sensitive requests visible only to the people involved in the workflow.
Data used to operate the service
BurnDrop stores account, workspace, request metadata, audit events, subscription limits and encrypted payload records needed to run the application.
- Recipient email and name entered by the sender.
- Request status, expiry, open count and approval metadata.
- Encrypted messages, encrypted responses and encrypted files.
- Operational data such as IP address, user agent and timestamps for audit and security.
Data handling principles
The service should be configured so sensitive exchange data is kept for the shortest practical time and access is scoped to the active tenant.
- Use UTC timestamps for retention and audit consistency.
- Keep public links unguessable and expire them promptly.
- Download or export completed responses into the customer system of record.
- Remove expired and completed exchange payloads after the configured retention period.
Privacy is easier when sensitive files do not live everywhere.
Use secure requests for intake, then move documents to the system designed to retain them.