Data Loss Prevention Strategy

This Data Loss Prevention Strategy describes the technical and organisational controls TruSend applies to keep customer data within the customer’s own tenant, to restrict access to customer data to authorised personnel and systems, and to limit personal data in logs, test environments, outgoing replies and content sent to AI models.

This page is published for information. It does not form part of the Data Processing Agreement or the Terms of Service; the measures we commit to are those in Annex II of our Data Processing Agreement. Incidents are handled under our Security Incident Response Policy.

1. Data categories and storage locations

• Conversations, contacts and attachments — Neon Postgres in AWS eu-central-1 (Frankfurt) and Cloudflare R2 in the EU jurisdiction, plus the Portal’s browser storage on your team’s devices.
• Integration data (Shopify customers and orders, WordPress, Meta, WhatsApp, email) — stored in our database: data retrieved from an integration is stored in the conversation record, and the integration’s access tokens are stored in the workspace’s integration settings.
• Account data — our identity provider, whose database is on Neon, with sign-in sessions on our servers at Hetzner in Nuremberg, Germany. Payment card details are collected and processed by Paddle, our merchant of record; TruSend does not receive or store full card numbers.
• Content sent to AI models — the AI model router, located in the United States, and the model providers it routes to, as listed on the subprocessors page.
• Telemetry — Grafana Cloud for logs and metrics, Sentry for error reports, PostHog for product analytics.
• Correspondence — email sent to our trusend.ai addresses, including any customer data you send us, is held in Google Workspace, as listed on the subprocessors page.

2. Controls in production

Tenant isolation

Access to customer data requires an authenticated connection, and the organisation is determined from that connection, not from data supplied in the request. Queries for customer data are scoped to that organisation. Server routes are recorded in an authorisation inventory, and an automated test checks that the inventory matches the code.

Least-privilege roles

Role-based permissions (owner, admin, support, chat member and knowledge-base permissions) are enforced on the server, not only in the user interface. Workspace defaults locked by an administrator are enforced on the server.

Personnel access

Access to production systems is restricted to a limited number of authorised TruSend personnel. The application provides no function through which TruSend personnel can read a customer organisation’s conversations. Administrative functions reserved to TruSend personnel are limited to usage budgets, quotas and AI model routing. Logins by TruSend personnel to our servers are logged and attributed to the individual. Database sessions opened through our operations tooling are logged with the individual, the target organisation and the stated reason. Personnel use two-step authentication on our database and storage provider accounts.

Passwords for product accounts

Passwords for product accounts must be at least 12 characters long, differ from the username and from the last 3 passwords used, and must not be on a list of commonly used passwords. The policy is enforced on the server.

Encryption in transit

Public connections are encrypted with TLS: from browsers and widgets to Cloudflare, and from Cloudflare to our servers through Cloudflare Tunnel. Database connections require TLS, and storage and AI model providers are accessed over HTTPS. Traffic between our servers is carried over WireGuard tunnels, and our servers are configured to reject unencrypted traffic from one another.

Encryption at rest

Neon encrypts the database and its backups (AES-256), and Cloudflare R2 encrypts stored objects. On our servers, customer data and credentials are stored on encrypted volumes whose keys are not stored on the server that holds them. Swap space is encrypted with a key regenerated at each boot, and temporary files are held in memory.

Backups

Backups of customer data are provided by Neon: point-in-time recovery for 7 days and daily snapshots kept 7 days, both encrypted. Neon also keeps its own encrypted backups for 30 days. No server-level backups are taken. Manual database exports are permitted only if encrypted before being written to storage, with the encryption key stored separately from the export.

Separate environments

Test and production run with different cloud providers, accounts, databases, identity realms, keys and domains. Production data is not copied to test.

Protection in the browser

Unsent drafts are encrypted with an AES-256-GCM key issued by our server, which is held only in memory and is valid for 8 hours; drafts are written to browser storage only in encrypted form. Contact email addresses, phone numbers and bios are encrypted in the Portal’s local database. If the encryption key cannot be obtained, these fields may be stored temporarily unencrypted and are encrypted once the key is available.

Detection of sensitive numbers in outgoing replies

The message composer detects payment card numbers (validated by the Luhn algorithm), IBANs, US Social Security numbers and Russian SNILS numbers, blocks the reply from being sent (this does not apply to internal notes), and records an audit event stating the type of number detected but not its value. The server repeats the check and, by default, blocks the message.

PII redaction before AI

Email addresses, phone numbers, card numbers and IP addresses detected in content sent to AI models are removed before it is sent. This includes content sent for translation, conversation summaries and the indexing and search of the knowledge base. Contact details that a workspace publishes for its customers in its knowledge base are not removed. Images, voice messages, videos and scanned documents that customers send are sent to an AI model as they are; the removal applies to the text produced from them.

Telemetry and logging

• In the browser, Sentry is loaded only after the user consents to analytics, is configured not to send default personal data, and applies a sanitiser to each event that removes tokens, links, email addresses and phone numbers.
• On the server, an automated test that blocks the build checks that email addresses, usernames and names are not written to log lines at INFO level and above; email addresses in exception messages are masked; and debug logging is disabled in production. Service and security logs record the IP address of each request and are kept for 14 days; request bodies are not written to logs, and email addresses are masked before logs are sent to Grafana Cloud.
• Product analytics events are recorded by our servers and, only after the user consents to analytics, sent from the Portal. Our servers do not record events for users who have objected to this processing or whose data has been erased, and events already recorded for a user who objects are deleted.

Audit trail

Changes to settings and accounts are logged with the person who made the change, the time, and the values before and after the change; secret values are masked. Changes to AI configuration are recorded in a separate log with the same detail.

API keys

API keys are displayed in full only once, at creation, and are masked afterwards. They are stored hashed and encrypted. Each workspace can have two active keys at a time.

3. Retention

• Conversations, contacts, attachments — for as long as the workspace exists, subject to the contact retention policy configured for that workspace. A deleted workspace and the files stored with it are deleted from production systems 30 days after the workspace is deleted, a period during which it can be restored, and from database recovery history within a further 7 days; copies in our database provider’s own encrypted backups expire within 30 days.
• Shopify and WordPress context in a conversation — 30 days after its last refresh, then removed automatically.
• AI action logs — up to 13 months.
• Settings, account and AI configuration audit trails — 90 days; changes to contact retention policies and legal holds on contacts — 7 years.
• Product analytics events — 25 months from the user’s last recorded activity.
• Records of data subject requests and data exports — 7 years.
• Database recovery — 7 days of point-in-time history and daily snapshots kept 7 days; our database provider’s own encrypted backups, 30 days.

4. Shopify data

• Scopes — read_customers and read_orders. The app writes to a store only its own app metafield, which identifies the TruSend workspace to be opened by the theme extension.
• Customer lookup — only when a conversation’s contact has an email address and the store is connected. The lookup uses an exact email match, and the result is labelled “matched by email” to indicate that it is not a verified identity.
• Order status in AI answers — when the store is connected, the AI agent can look up an order by its number together with the email address used for it. Only the order number, date, statuses, carrier and tracking details are sent to the AI model; the customer’s name, address and email address are not.
• Data stored — name, email, phone, number of orders, total spent, tags, and the five most recent orders from the last 60 days (number, payment and fulfilment status, total, date), stored in that conversation’s record.
• Deletion — 30 days after the last refresh; for one customer on Shopify’s customers/redact request; for the whole store, with its tokens, on shop/redact. Uninstalling the app disconnects the store immediately; Shopify data already stored is deleted as described above.
• Tokens — expiring Shopify tokens, kept server-side. The refresh token is not displayed in the interface.
• Logs — customer data from Shopify is not written to logs; compliance requests are logged by their identifiers only.

5. Monitoring and detection

Potential data security incidents are identified through server logs, including database sessions and schema changes run by TruSend personnel through our operations tooling; error tracking; the log of personnel access to production systems; reports from third parties to security@trusend.ai (also published at /.well-known/security.txt); and notices from subprocessors. Indications of a potential incident are handled under our Security Incident Response Policy.

6. Shopify protected customer data requirements

• Process only the minimum personal data, for stated purposes — met; see section 4.
• Apply retention periods — met; see section 3.
• Encrypt data at rest and in transit — met; see Encryption in transit and Encryption at rest in section 2.
• Encrypt data backups — met; see Backups in section 2.
• Keep test and production data separate — met; see Separate environments in section 2.
• Have a data loss prevention strategy — met; this document.
• Limit staff access to protected customer data — met; see Personnel access in section 2.
• Require strong passwords for staff accounts — met; two-step authentication on the database and storage provider accounts used by personnel, and the password policy in section 2 for product accounts.
• Keep an access log to protected customer data — met; see Personnel access in section 2.
• Implement a security incident response policy — met; see the Security Incident Response Policy, under which a suspected breach involving data received from Shopify is reported to Shopify within 24 hours.

7. Review

This strategy is reviewed at intervals of 12 months, after each SEV-1 security incident as defined in the Security Incident Response Policy, and when a new subprocessor or integration begins processing personal data.