Subprocessors
Last updated: July 9, 2026
SLDocs uses the third-party service providers listed below to deliver the service. We publish this list to give our users — individual customers and the law firms we serve — full visibility into who processes their data and on what terms.
Document content protection. Every document uploaded to SLDocs is encrypted with a per-document AES-256-GCM key that is itself wrapped by a Google Cloud KMS key unique to the account — a per-user key for individual accounts, and a tenant-scoped key for accounts managed by a law firm. The "Sees" column below shows what each provider can actually access: most providers see only ciphertext or metadata, never plaintext document content. Where a provider must briefly see plaintext (fax delivery, virus scanning), the plaintext is held only in memory or in a short-lived temporary object that is deleted immediately after use.
| Provider | Purpose | Sees | Region |
|---|---|---|---|
| Vercel Application hosting & edge compute | Hosts the SLDocs application, terminates TLS, routes requests, runs server-side code. Data processed: All HTTP request data (IP addresses, headers, request paths, form submissions in transit). | plaintext (transient) | United States (Global edge) |
| Neon PostgreSQL database | Stores account records, document metadata, audit logs, billing records, and other structured data. Data processed: User names, email addresses, hashed passwords, document filenames and metadata, recipient/trusted-contact records, billing records, audit log entries. | no document content | United States |
| Cloudflare R2 Encrypted object storage | Stores user-uploaded documents as encrypted ciphertext blobs. Data processed: AES-256-GCM-encrypted document ciphertext only — never plaintext. The data-encryption keys are wrapped by Google Cloud KMS (US) and are never sent to R2, so the stored bytes are cryptographically unrecoverable without keys that never leave the United States. | ciphertext only | Global (ciphertext; keys US-only) |
| Google Cloud KMS Encryption key management | Wraps and unwraps the per-document data encryption keys (DEKs) that protect document ciphertext. Operates the envelope-encryption layer. Data processed: KMS-wrapped DEK blobs. The plaintext DEKs exist only in process memory during a single decryption operation and are zeroed afterward. | no document content | United States (configurable per tenant) |
| Resend Transactional email | Sends authentication emails (verification, password reset, two-factor codes), invite emails, notification emails, and other transactional messages. Data processed: Recipient email addresses, user names, message subjects and bodies, delivery metadata. Document sharing is delivered as a secure LINK to the in-app reader — no document content is ever attached to or sent through email. | no document content | United States |
| Migadu Email hosting (inbound mailboxes) | Hosts the receiving mailboxes for human correspondence (support, legal, and security inboxes). Outbound transactional email is sent via Resend, not Migadu. Data processed: Email addresses, names, and the contents of messages users send to us — which for support correspondence may include account details and sensitive narrative about a user's documents or estate. Migadu does not apply application-layer encryption to mailbox contents at rest. | no document content | Not published by Migadu — Swiss company hosting on OVHcloud (data centers in North America, Europe, and APAC); mailbox data may reside outside the U.S. |
| Stripe Payments | Processes B2C subscription payments, B2B firm billing, and one-time add-on purchases. Hosts the checkout flow and customer billing portal. Data processed: Customer name, email, billing address, card / payment-method tokens. SLDocs never stores card numbers — Stripe handles them under PCI DSS. | no document content | United States (Global) |
| Telnyx SMS & fax delivery | Delivers account and security text messages (two-factor sign-in codes, document-access codes, and account notifications) when you opt in to SMS, and delivers documents by fax via Programmable Fax when a user purchases the fax-delivery add-on. Data processed: Mobile and fax numbers and message content. For SMS: the recipient mobile number and the text of the message (security codes, access links, notifications) — no document content. For fax: sender / recipient fax numbers and the document being faxed — plaintext document content is decrypted server-side, uploaded to a short-lived presigned URL (1-hour expiry, deleted after delivery), and provided to Telnyx. | plaintext (transient) | United States |
| Cloudmersive Virus scanning | Scans uploaded documents for malware before they are released into the user's vault. Documents are decrypted server-side and submitted to Cloudmersive for scanning; the plaintext is discarded after the scan returns a verdict. Data processed: Document content (plaintext, transient) and scan result. | plaintext (transient) | United States |
| Sentry Server-side error monitoring & security reports | Captures unhandled server-side errors and exceptions from SLDocs application servers to help diagnose and fix bugs. SLDocs uses Sentry server-side only. No tracking SDKs or cookies are used and no Sentry browser SDK is loaded. Browsers natively send us Content-Security-Policy violation reports, which we retain for 90 days and use solely for security monitoring. Data processed: Server stack traces, error messages, the URL path and HTTP method of the failing request, a small set of request headers, and browser security reports (page URL, blocked resource URL, and user-agent). We do not send document content, encryption keys, full request bodies, or user PII to Sentry (sendDefaultPii is disabled). User IDs may appear in error context where strictly needed to reproduce an issue. CSP security reports are scrubbed of query strings to remove tokens before transmission to Sentry. | no document content | United States |
| Amazon Web Services (S3) Off-site encrypted backup storage | Stores the provider-independent backup tier: a nightly PostgreSQL database backup and hourly copies of the encrypted document objects, so the service can be restored if a primary provider fails. Data processed: The nightly database backup (account records, document metadata, the audit log, recipient/trusted-contact records) is AES-256-GCM encrypted on the backup runner under a per-run key — itself wrapped by a Google Cloud KMS key — BEFORE it is uploaded, so AWS holds only ciphertext plus a KMS-wrapped key it cannot unwrap. AWS also stores hourly copies of the AES-256-GCM-encrypted document ciphertext mirrored from R2. No encryption key is ever sent to AWS, so neither the database backup nor the document bytes are recoverable by AWS. | ciphertext only | United States |
| GitHub (Actions) Backup automation & CI/CD | Runs the scheduled backup workflows that copy the database and encrypted documents to off-site storage, and builds and deploys the application. Data processed: During the nightly backup job the runner transiently handles the plaintext PostgreSQL dump (account records, metadata, audit log) — it is the encryptor, AES-256-GCM-encrypting the dump on the runner before upload — and streams encrypted document ciphertext from R2 to S3. The monthly restore-verification job transiently decrypts one backup on the runner to confirm restorability. Nothing is retained on the runner after a job; document plaintext and encryption keys never reach it. | ciphertext only | United States |
| PostHog Beta product analytics (client-side, cookieless) | Measures how enrolled beta testers navigate and use the product during the pre-launch beta (pageviews and explicit in-product events) so SLDocs can improve it. Runs only for signed-in beta testers who acknowledged beta session tracking at signup; removed when the beta ends. Data processed: Pageviews and explicit in-product interaction events tied to the tester's account, plus session technical data (IP address, browser user-agent). Cookieless — stores nothing on the device (no cookies, no local/session storage). Autocapture and session recording are off, so no document contents, form entries, or vault data are captured. Processed solely as SLDocs's service provider, only for SLDocs's own product improvement. | no document content | United States (PostHog US Cloud) |
Hosts the SLDocs application, terminates TLS, routes requests, runs server-side code.
Data processed: All HTTP request data (IP addresses, headers, request paths, form submissions in transit).
- Region
- United States (Global edge)
Stores account records, document metadata, audit logs, billing records, and other structured data.
Data processed: User names, email addresses, hashed passwords, document filenames and metadata, recipient/trusted-contact records, billing records, audit log entries.
- Region
- United States
Stores user-uploaded documents as encrypted ciphertext blobs.
Data processed: AES-256-GCM-encrypted document ciphertext only — never plaintext. The data-encryption keys are wrapped by Google Cloud KMS (US) and are never sent to R2, so the stored bytes are cryptographically unrecoverable without keys that never leave the United States.
- Region
- Global (ciphertext; keys US-only)
Wraps and unwraps the per-document data encryption keys (DEKs) that protect document ciphertext. Operates the envelope-encryption layer.
Data processed: KMS-wrapped DEK blobs. The plaintext DEKs exist only in process memory during a single decryption operation and are zeroed afterward.
- Region
- United States (configurable per tenant)
Sends authentication emails (verification, password reset, two-factor codes), invite emails, notification emails, and other transactional messages.
Data processed: Recipient email addresses, user names, message subjects and bodies, delivery metadata. Document sharing is delivered as a secure LINK to the in-app reader — no document content is ever attached to or sent through email.
- Region
- United States
Hosts the receiving mailboxes for human correspondence (support, legal, and security inboxes). Outbound transactional email is sent via Resend, not Migadu.
Data processed: Email addresses, names, and the contents of messages users send to us — which for support correspondence may include account details and sensitive narrative about a user's documents or estate. Migadu does not apply application-layer encryption to mailbox contents at rest.
- Region
- Not published by Migadu — Swiss company hosting on OVHcloud (data centers in North America, Europe, and APAC); mailbox data may reside outside the U.S.
Processes B2C subscription payments, B2B firm billing, and one-time add-on purchases. Hosts the checkout flow and customer billing portal.
Data processed: Customer name, email, billing address, card / payment-method tokens. SLDocs never stores card numbers — Stripe handles them under PCI DSS.
- Region
- United States (Global)
Delivers account and security text messages (two-factor sign-in codes, document-access codes, and account notifications) when you opt in to SMS, and delivers documents by fax via Programmable Fax when a user purchases the fax-delivery add-on.
Data processed: Mobile and fax numbers and message content. For SMS: the recipient mobile number and the text of the message (security codes, access links, notifications) — no document content. For fax: sender / recipient fax numbers and the document being faxed — plaintext document content is decrypted server-side, uploaded to a short-lived presigned URL (1-hour expiry, deleted after delivery), and provided to Telnyx.
- Region
- United States
Scans uploaded documents for malware before they are released into the user's vault. Documents are decrypted server-side and submitted to Cloudmersive for scanning; the plaintext is discarded after the scan returns a verdict.
Data processed: Document content (plaintext, transient) and scan result.
- Region
- United States
Captures unhandled server-side errors and exceptions from SLDocs application servers to help diagnose and fix bugs. SLDocs uses Sentry server-side only. No tracking SDKs or cookies are used and no Sentry browser SDK is loaded. Browsers natively send us Content-Security-Policy violation reports, which we retain for 90 days and use solely for security monitoring.
Data processed: Server stack traces, error messages, the URL path and HTTP method of the failing request, a small set of request headers, and browser security reports (page URL, blocked resource URL, and user-agent). We do not send document content, encryption keys, full request bodies, or user PII to Sentry (sendDefaultPii is disabled). User IDs may appear in error context where strictly needed to reproduce an issue. CSP security reports are scrubbed of query strings to remove tokens before transmission to Sentry.
- Region
- United States
Stores the provider-independent backup tier: a nightly PostgreSQL database backup and hourly copies of the encrypted document objects, so the service can be restored if a primary provider fails.
Data processed: The nightly database backup (account records, document metadata, the audit log, recipient/trusted-contact records) is AES-256-GCM encrypted on the backup runner under a per-run key — itself wrapped by a Google Cloud KMS key — BEFORE it is uploaded, so AWS holds only ciphertext plus a KMS-wrapped key it cannot unwrap. AWS also stores hourly copies of the AES-256-GCM-encrypted document ciphertext mirrored from R2. No encryption key is ever sent to AWS, so neither the database backup nor the document bytes are recoverable by AWS.
- Region
- United States
Runs the scheduled backup workflows that copy the database and encrypted documents to off-site storage, and builds and deploys the application.
Data processed: During the nightly backup job the runner transiently handles the plaintext PostgreSQL dump (account records, metadata, audit log) — it is the encryptor, AES-256-GCM-encrypting the dump on the runner before upload — and streams encrypted document ciphertext from R2 to S3. The monthly restore-verification job transiently decrypts one backup on the runner to confirm restorability. Nothing is retained on the runner after a job; document plaintext and encryption keys never reach it.
- Region
- United States
Measures how enrolled beta testers navigate and use the product during the pre-launch beta (pageviews and explicit in-product events) so SLDocs can improve it. Runs only for signed-in beta testers who acknowledged beta session tracking at signup; removed when the beta ends.
Data processed: Pageviews and explicit in-product interaction events tied to the tester's account, plus session technical data (IP address, browser user-agent). Cookieless — stores nothing on the device (no cookies, no local/session storage). Autocapture and session recording are off, so no document contents, form entries, or vault data are captured. Processed solely as SLDocs's service provider, only for SLDocs's own product improvement.
- Region
- United States (PostHog US Cloud)
Adding or changing subprocessors
We will update this page whenever we add, remove, or materially change a subprocessor, and we will email subscribers below at least 30 days before any change takes effect.
Sub-subprocessors
The providers listed above may themselves rely on their own infrastructure providers (cloud regions, CDNs, etc.). We assess each subprocessor for adequate security and contractual controls before onboarding them, but we do not publish the full subprocessor tree of every vendor — refer to each provider's own subprocessors page, linked from their privacy policy above.
Contact
Questions about our subprocessors or data practices? Email legal@sldocs.com.
Please don't email sensitive personal or health information or documents — email isn't encrypted and may be stored outside the U.S. Use your in-product vault instead.