Last reviewed: June 26, 2026
This page is intended for vendor onboarding, procurement, and security review teams. It provides a structured overview of how Tesults approaches data security and compliance, what controls are in place, and how we can support your review process. Tesults processes operational test and diagnostic data rather than production customer data, applies strong technical controls regardless of certification status, and aims to be transparent about what we do and do not have in place.
Tesults runs on infrastructure that holds SOC 2 and ISO 27001 certifications (Amazon Web Services). At the application layer, Tesults applies strong technical controls and operates with a commitment to transparency. Tesults is not currently SOC 2 Type II or ISO 27001 certified at the company level. As a focused SaaS product that processes operational test and diagnostic data, we prioritize strong technical controls and direct transparency while running on infrastructure that is itself certified. We can support customer security reviews directly and will complete security questionnaires on request.
The physical infrastructure and network layers of the Tesults service are provided by Amazon Web Services (AWS), which holds the following certifications and attestations: SOC 1, SOC 2, SOC 3, ISO 27001, ISO 27017 and ISO 27018. Payment processing is handled entirely by Stripe, which is certified to PCI DSS Service Provider Level 1. Tesults does not directly store or transmit full payment card data. Only the Tesults application layer is self-attested rather than independently audited by a third party.
Tesults is built to store test execution data: test names, pass and fail status, run timings, error messages, stack traces, and the diagnostic logs and attachments produced by automated and manual testing. By design and in typical use this is operational and diagnostic data, not production customer records, personal data, or financial data. For most customers this means the inherent sensitivity of data held in Tesults is lower than that of systems processing production personal or financial information, and many security teams are able to classify Tesults into a lighter review tier accordingly.
This describes the typical profile, not a guarantee about every field. Because customers control what they upload, logs, screenshots, and attachments can in some cases contain data a customer considers sensitive. The controls described on this page apply to all data stored in Tesults regardless of sensitivity, and the decision about what to upload rests with the customer, as set out below.
Tesults is designed for test results, diagnostic data, and CI pipeline data. Customers control what they upload to the service, including test result logs, file attachments, and screenshots. Customers are responsible for ensuring they have the right to upload the data they submit and that doing so complies with applicable law and their own internal policies. Customers should avoid uploading sensitive or regulated data where it is not required for their testing purposes. This is a shared responsibility model: Tesults secures the platform and the data stored on it, and customers are responsible for the data they choose to upload.
The following table maps common security control areas to what Tesults has in place. All controls listed here are verified and documented in the Tesults security documentation and terms of service.
| Control area | What Tesults does |
|---|---|
| Data in transit | TLS/HTTPS end to end, including all result APIs and language libraries. |
| Data at rest | Data is encrypted at rest. Authentication data is encrypted at rest, and test results data is encrypted using Tesults private keys for self-serve plans (Free, Standard, Plus). Bring-your-own-keys is available on Enterprise. |
| Authentication | Two-factor authentication (2FA) available to all users. |
| Access and SSO | SAML 2.0 and Google OAuth SSO available on all plans. |
| Authorization | Role-based access control, least-privilege by default. New team members receive level 1 (least permissive) access. Payment access restricted to level 4. Card details are never displayed or transmitted beyond the last 4 digits and expiry. |
| Audit logging | Audit logs available on all paid plans. |
| Payments | Handled by Stripe (PCI DSS Service Provider Level 1). Tesults does not store full card data. |
| Data residency | Customer test data is stored in United States data centers on AWS. |
| API security | All internal and external APIs require authentication. |
Test results data is backed up automatically on a regular cadence using geographically redundant infrastructure. Backups are managed within the AWS infrastructure layer. Tesults does not currently publish specific recovery point objectives (RPO) or recovery time objectives (RTO), and does not provide a service level agreement (SLA) on uptime. Contact help@tesults.com for specific questions on data recovery capabilities.
In the event of a confirmed data breach affecting customer data, Tesults will notify affected customers without undue delay after becoming aware of the incident.
Test results data is deleted on a rolling basis. Retention periods by plan are:
You can request permanent deletion of your data at any time by contacting help@tesults.com. Tesults will complete the request and respond within 30 days. Deleted data is permanently removed and cannot be recovered.
Tesults relies on the following third-party subprocessors:
We are happy to support your security review process directly. We can complete security questionnaires including SIG Lite and CAIQ, work with you to put appropriate data processing terms in place, and answer specific technical questions about our architecture and controls. Contact help@tesults.com for all vendor onboarding, due diligence, and security review requests, consistent with how we handle requests through our vendor onboarding page.
For a broader overview of our technical security controls, see the security documentation. For general vendor onboarding and due diligence information, see the vendor onboarding page.