Subprocessors
Last updated: July 31, 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 key-encryption material managed in Google Cloud KMS. For an active individual account, that key material is isolated to the account; for accounts managed by a law firm, it is isolated to the firm’s tenant. SLDocs manages and operates the KMS keys; customers do not separately hold or operate them. 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), that plaintext exists only in server memory for the length of the operation — it is never written to storage in readable form. When fax media has to wait for the carrier to collect it, what is stored is a separately encrypted copy under its own key, retrieved through a single-purpose link that decrypts on demand and is revoked once the fax completes.
| Provider | Purpose | Sees | Region |
|---|---|---|---|
| Vercel Application hosting & edge compute | Hosts the SLDocs application, terminates TLS, routes requests, runs server-side code. Where enabled, also runs Vercel's basic BotID challenge on public signup and contact forms as a strictly necessary fraud-and-abuse control. Data processed: All HTTP request data (IP addresses, headers, request paths, form submissions in transit). Where the basic BotID challenge is enabled, the challenge token accompanying a protected form submission. No device fingerprinting and no deep-analysis signals. | 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. For active direct-consumer accounts, key-encryption material is isolated per account; for firm accounts, it is isolated per tenant. SLDocs manages and operates the KMS keys. 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 |
| MXroute Email hosting (inbound mailboxes) | Hosts the receiving mailboxes for human correspondence (the admin, general, support, legal, and security inboxes). Outbound transactional email is sent via Resend, not MXroute. 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. MXroute does not apply application-layer encryption to mailbox contents at rest. | no document content | United States |
| 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. Because Telnyx collects fax media on its own schedule after a send is queued, the document is decrypted and converted to fax-ready form only in server memory, then re-encrypted under a fresh AES-256-GCM key — wrapped by the same Google Cloud KMS key that protects the original — before anything is stored; only that ciphertext is written, under a name that identifies no person or purchase. Telnyx retrieves it through a single-purpose link that decrypts on demand, expires within 15 minutes, and is revoked as soon as the fax succeeds or fails. Telnyx therefore sees the plaintext document only for the transmission itself. | 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 Sentry 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 Product analytics and session replay (beta period only; scheduled for removal at the end of the beta period) | Measures how consenting beta testers navigate and use the product during the pre-launch beta so SLDocs can improve it, for three purposes: analytics, debugging, and product enhancement. Runs only for signed-in testers who consented at signup; removed when the beta ends. Data processed: Usage events, device and browser metadata, masked session recordings. With a tester’s consent, PostHog records navigation and interaction during the beta on screens SLDocs specifically permits, including clicks, scrolling, page transitions, and ordinary interface selections. A new or unrecognized screen is not recorded unless SLDocs expressly adds it. Medical and emergency-medical screens are never recorded. On recorded screens, everything the tester types and text derived from the tester or stored data are masked, except that a value identical to fixed interface text may appear as that interface text. Fixed interface text may remain readable. Sensitive controls and statuses are blocked. The tester is identified only by a random internal account identifier — not name or email. 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. Where enabled, also runs Vercel's basic BotID challenge on public signup and contact forms as a strictly necessary fraud-and-abuse control.
Data processed: All HTTP request data (IP addresses, headers, request paths, form submissions in transit). Where the basic BotID challenge is enabled, the challenge token accompanying a protected form submission. No device fingerprinting and no deep-analysis signals.
- 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. For active direct-consumer accounts, key-encryption material is isolated per account; for firm accounts, it is isolated per tenant. SLDocs manages and operates the KMS keys.
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 (the admin, general, support, legal, and security inboxes). Outbound transactional email is sent via Resend, not MXroute.
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. MXroute does not apply application-layer encryption to mailbox contents at rest.
- Region
- United States
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. Because Telnyx collects fax media on its own schedule after a send is queued, the document is decrypted and converted to fax-ready form only in server memory, then re-encrypted under a fresh AES-256-GCM key — wrapped by the same Google Cloud KMS key that protects the original — before anything is stored; only that ciphertext is written, under a name that identifies no person or purchase. Telnyx retrieves it through a single-purpose link that decrypts on demand, expires within 15 minutes, and is revoked as soon as the fax succeeds or fails. Telnyx therefore sees the plaintext document only for the transmission itself.
- 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 Sentry 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 consenting beta testers navigate and use the product during the pre-launch beta so SLDocs can improve it, for three purposes: analytics, debugging, and product enhancement. Runs only for signed-in testers who consented at signup; removed when the beta ends.
Data processed: Usage events, device and browser metadata, masked session recordings. With a tester’s consent, PostHog records navigation and interaction during the beta on screens SLDocs specifically permits, including clicks, scrolling, page transitions, and ordinary interface selections. A new or unrecognized screen is not recorded unless SLDocs expressly adds it. Medical and emergency-medical screens are never recorded. On recorded screens, everything the tester types and text derived from the tester or stored data are masked, except that a value identical to fixed interface text may appear as that interface text. Fixed interface text may remain readable. Sensitive controls and statuses are blocked. The tester is identified only by a random internal account identifier — not name or email. 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 a secure channel and messages are stored unencrypted at rest. Use your in-product vault instead.