Data processing addendum

Effective 17 October 2026

This data processing addendum ("DPA") forms part of the terms of service (the "Agreement") between Carrier Grade Inc., 2665 S Bayshore Dr, Miami, FL 33133, United States ("Processor", "we"), and the customer using Testlie ("Controller", "you"). It applies automatically to every customer whose Customer Data includes personal data subject to the EU General Data Protection Regulation (GDPR), the UK GDPR, the Swiss Federal Act on Data Protection, or US state privacy laws such as the California Consumer Privacy Act (together, "Data Protection Laws"). No signature is needed; Enterprise customers can ask for a countersigned copy at hello@testlie.com. Terms defined in the Agreement have the same meaning here; "personal data", "processing", "controller", "processor" and "personal data breach" have the meanings given in the GDPR.

1. Roles of the parties

  • Customer Data. For personal data in Customer Data, you are the controller (or a processor acting for your own customer) and we are your processor (or subprocessor). We process it only to provide the Service to you.
  • Account data. For account data about your users (names, email addresses, sign-ins, billing details, support messages and website usage), we are an independent controller, as described in our privacy policy. This DPA does not apply to account data.
  • Service providers. Where US state laws apply, we act as your "service provider" or "processor". We will not sell or share Customer Data, retain, use or disclose it for any purpose other than providing the Service, or combine it with personal data we receive from other sources, except as those laws allow.

2. Subject matter, duration and purpose

We process Customer Data to provide the Service under the Agreement: to receive, store, analyse, display and delete what your applications send to the sandboxes, to run the mock identity providers and checks you use, and to deliver data to destinations you configure. Processing lasts for the term of the Agreement and until Customer Data is deleted under section 10.

3. Details of the processing

Categories of data subjects People who appear in content your applications send to the Service: typically test users and your own staff, and possibly your end users or anyone who writes to an inbound address or request bin; test users you define in mock identity providers
Categories of personal data Names, email addresses, phone numbers, device tokens and any other content of captured email, text and WhatsApp messages, push notifications, call transcripts, inbound deliveries and HTTP requests (including headers, IP addresses and attachments); test user profiles, groups and claims; credentials and endpoints you configure
Special categories None intended. You should not send special categories of personal data, or payment card or health data, to a test environment
Frequency Continuous, for as long as you use the Service
Retention According to your plan's retention period and your inbox and sandbox limits, as set out in the privacy policy, and until deletion under section 10

Processing activities

Activity Processing
Email capture Receiving email over SMTP and at inbound addresses, storing it, rendering it in a sandboxed preview, and running HTML, link, accessibility, authentication and spam checks. Spam checks send DNS queries containing IP addresses and domain names from the message to DNS blocklist services; link checks request the URLs in the message
SMS and SMPP Receiving text messages through the Twilio-compatible API and the SMPP server, storing them and simulating delivery statuses and receipts
WhatsApp Receiving messages and media through the WhatsApp Cloud API emulation, simulating users and statuses, and sending webhooks to the callback URL you configure
Push notifications Receiving APNs and FCM requests, verifying them with test keys, storing notifications and simulating device outcomes. Uploaded APNs keys are read to derive a public key; the private key is not kept
Voice and OTP calls Receiving call requests, fetching TwiML from your URLs, simulating the callee and storing the transcript
Inbound deliveries Sending simulated messages and emails to your application's endpoints and storing the exchange
Mock identity providers and SCIM Storing test users, signing tokens and assertions, logging sign-in activity, and sending SCIM requests to the endpoint you configure
Request bins Recording HTTP requests sent to your bins and returning the responses you configure
Automation Webhooks, integrations, forwarding to confirmed addresses, the API and failure scenarios
Operations Hosting, backups, monitoring, security, support and deletion

4. Processor obligations

We will:

  • process Customer Data only on your documented instructions, which are the Agreement, this DPA and your configuration and use of the Service, unless the law requires otherwise (in which case we will tell you first, unless the law forbids it), and tell you if we believe an instruction breaks Data Protection Laws;
  • ensure that people authorised to process Customer Data are bound by confidentiality;
  • implement and maintain the technical and organisational measures in Annex 1;
  • taking into account the nature of the processing, assist you with requests from data subjects, with data protection impact assessments and prior consultations, and with your security obligations;
  • notify you without undue delay, and in any event within 48 hours, after becoming aware of a personal data breach affecting Customer Data, as set out in section 7;
  • make available the information needed to demonstrate compliance with this DPA and allow audits as set out in section 9.

5. Your obligations

You are responsible for the lawfulness of the personal data you send to the Service and for any notices and consents it requires; for choosing a plan and limits whose retention fits your needs, and deleting data sooner where needed; for the credentials and endpoints you configure; for forwarding messages and sending webhooks only to destinations you are entitled to send them to; and for complying with the acceptable use policy.

6. Subprocessors

You give us general authorisation to engage the subprocessors listed on the subprocessors page. We will give at least 30 days' notice of a new subprocessor by updating that page and emailing team owners who have asked to be notified at hello@testlie.com. You may object on reasonable data protection grounds within that period; if we cannot address the objection, you may cancel the affected Service and receive a refund of prepaid fees for the unused period. We impose data protection obligations on each subprocessor that are no less protective than this DPA, and we remain responsible for their performance.

7. Personal data breaches

If we become aware of a personal data breach affecting Customer Data, we will notify the team owners by email within 48 hours, and will provide, as soon as it is available, a description of the breach, the categories and approximate number of data subjects and records concerned, its likely consequences, and the measures taken or proposed. We will take reasonable steps to contain and remedy the breach. Our notification is not an admission of fault.

8. International transfers

Customer Data is hosted in the EU (Amazon Web Services, Ireland, eu-west-1). Carrier Grade Inc. is based in the United States, and some subprocessors process data outside the EEA, as listed with their locations on the subprocessors page. Where Customer Data is transferred from the EEA, the UK or Switzerland to a country without an adequacy decision, the parties agree to the EU Standard Contractual Clauses (Module 2 where you are a controller, Module 3 where you are a processor), which are incorporated by reference, with: clause 7 (docking) applying; option 2 of clause 9 (general authorisation, with the notice period in section 6); the optional wording of clause 11 not applying; Irish law and the courts of Ireland for clauses 17 and 18; Annex I completed by sections 1 to 3 of this DPA; Annex II by Annex 1; and Annex III by the subprocessors page. For transfers from the UK, the UK International Data Transfer Addendum applies, and for transfers from Switzerland the clauses apply with the adjustments required by Swiss law. Onward transfers to subprocessors rely on the Standard Contractual Clauses or on the recipient's certification under the EU-U.S. Data Privacy Framework and its UK and Swiss extensions.

9. Audits

We will answer your reasonable written security questionnaires once a year and provide summaries of available third-party audit or certification reports of our hosting providers. If that is not enough to demonstrate compliance, or a supervisory authority requires it, you may audit our compliance with this DPA once a year on 30 days' written notice, during business hours, at your cost, through an independent auditor bound by confidentiality, and without access to other customers' data.

10. Deletion and return

Customer Data is deleted automatically under your plan's retention period and your inbox and sandbox limits, and when you delete it. You can export Customer Data through the API at any time. When the Agreement ends or your team is deleted, we delete the remaining Customer Data from the live systems within 30 days, and it is removed from backups when they expire (within a further 30 days), unless the law requires us to keep it.

11. Liability and precedence

Each party's liability under this DPA is subject to the limitations in the Agreement, except where Data Protection Laws do not allow it. If this DPA conflicts with the Agreement, this DPA prevails for the processing of Customer Data. If the Standard Contractual Clauses conflict with this DPA, the clauses prevail.

Annex 1: technical and organisational measures

Hosting and infrastructure

  • The Service runs on Amazon Web Services in the EU (Ireland). Server access is limited to named operators, using SSH keys from allow-listed addresses; firewall rules expose only the ports the Service needs.
  • Secrets such as payment and email provider keys are kept in a managed secrets store, not in source code.
  • Database backups are taken nightly and before every software release. Nightly backups are stored encrypted in access-restricted, versioned storage in the same region and expire after 30 days.
  • Health checks on the web, mail, SMS and job services alert operators, and incidents are published on the status page.

Encryption

  • All traffic to the web app and API uses TLS (HTTPS), and the app sends security headers. SMTP supports STARTTLS and implicit TLS and refuses passwords on unencrypted connections when TLS is available; SMPP is offered over TLS on a dedicated port.
  • Inbox SMTP passwords, SMPP passwords, SMS and WhatsApp sandbox tokens and secrets, webhook and request bin signing secrets, mock identity provider client secrets, SCIM tokens and the private keys of generated push credentials are encrypted at rest with AES-256-GCM. API keys are stored only as SHA-256 hashes. Passwords are hashed with scrypt; two-factor secrets are encrypted.

Access control and isolation

  • Every query is scoped to one team; requests for another team's data are answered as if it did not exist.
  • Roles (owner, admin, member) gate configuration; API keys can be read-only and can expire, and cannot manage people, keys or SSO.
  • Two-factor authentication, team single sign-on (OIDC and SAML) and sign-in restricted to company domains are available to customers.

Untrusted content

  • Message HTML is rendered in a sandbox: it is served with a strict Content-Security-Policy that blocks scripts, objects and frames, and shown in a sandboxed iframe. Request bin responses are served with a sandboxing Content-Security-Policy and no content sniffing. Attachments are always downloaded, never rendered in the app.
  • Remote images and stylesheets in messages load through an image proxy with signed URLs.
  • Outbound requests to customer-supplied URLs (webhooks, link checks, inbound deliveries, callbacks, SCIM and the image proxy) refuse private, loopback, link-local and reserved addresses, checked at connection time.

Data minimisation and deletion

  • Captured content is deleted automatically according to plan retention and per-inbox limits; stored objects of deleted messages are purged.
  • Uploaded APNs keys are reduced to their public part. SCIM bearer tokens are redacted from logs.
  • Forwarding only reaches addresses that have confirmed by email, with a loop guard; forwards are sent as a new message with the original attached.

Monitoring and accountability

  • Each team has an audit log of changes to inboxes, keys, webhooks, identity providers and forwarding, and of forwarded messages.
  • Sign-in, password reset, SMTP and SMPP connections, failed logins and selected API operations are rate limited.
  • Personal data breaches are investigated and affected Controllers notified as described in section 7.

Contact for data protection matters: hello@testlie.com.