Trelica is SOC 2 Type 2 certified and has a well-established security management programme. This is aligned with the ISO 27001 standard and covers all aspects of our operations, including our development process and our production environment. It is reviewed annually and driven directly by one of our executive team.
This organisational commitment to security is reflected in the functionality of our product.
OAuth2 (currently Microsoft Azure AD and Google Identity are supported)
SAML2 (e.g. Okta, OneLogin, PingOne, JumpCloud)
User name and password (with optional second factor provided by a Time-based One-Time Password (TOTP) generator app. Password strength rules are applied when passwords are created and password reset emails contain a link containing a time-limited token to reset the password.
Successful and failed authentication attempts, including the username, date/time, action and IP address of the connection, are stored in application audit logs.
Trelica runs on Microsoft Azure, which provides a secure, fault-tolerant environment. Our development environment is stored in the UK South Region and we deploy to East US 2 and Germany West Central (the latter being a hosting option for customers who require data to be held within the EU). Development and Pre-production environments are completely segregated in the UK South Azure location. Azure data centers maintain multiple certifications including ISO 27001, FedRAMP authorization and SOC2 reports.
Customer data is never copied to, or used in development or test environments.
As well as Microsoft Azure, we also use SendGrid to reliably send email notifications. SendGrid also has a SOC2 attestation.
All customer data is encrypted at rest, and HSTS headers are used to ensure that traffic from our infrastructure to your web-browser is encrypted using TLS. Trelica supports TLS 1.3 and 1.2, blocking older protocols.
We also encrypt traffic on our internal networks between application servers and our databases.
User passwords (where used) are stored as salted one-way hashes (SHA256). API keys, and OAuth2 refresh and access tokens entered or created when integrating with third-party systems are encrypted and stored in Azure Key Vault which is backed by FIPS validated hardware security modules (HSMs). Access is monitored and audited.
Data is stored in two separate database instances, in case of failure, and snapshots are taken daily and replicated to a secondary location at least 150 miles away but within the same jurisdiction. Database backups are retained for a period of 30 days.
Trelica has backup and restoration procedures which allow recovery from a major disaster.
Azure Network Security Groups are used to define inbound and outbound security rules providing a minimum set of firewall rules. The Trelica platform runs on Azure Kubernetes Service (AKS) which is on a separate vnet. AKS runs on multiple reserved-instance Azure VMs.
Logging and monitoring
There is a centralized logging system in place which aggregates log and performance metric data from multiple sources in the Trelica production environment. This allows staff to investigate security and performance issues effectively.
As well as running internal logging and analysis tools, we use external tools to monitor our production environment and have a publicly available status page showing current and past availability metrics.
Security In Our Business
All staff sign employment contracts that commit them to confidentiality undertakings, and are directly employed by Trelica. Staff are background-checked prior to starting work. Staff under-take a security induction as part of their onboarding process and receive training on an on-going basis, as appropriate to their role.
Hardware is centrally managed to ensure that anti-virus software is installed, that hard-drives are encrypted and that updates have been applied.
We have defined, documented, change control processes and standards for development including manual peer-review processes. New functionality and design changes undergo an additional security review. The Trelica platform has high automated unit-test coverage and all build and deployment processes are fully automated to ensure consistency.
We also have automated tools to analyze our source code for vulnerabilities.
Specific, standardized, architectural approaches are used to prevent common attack vectors such as cross-site request forgery attacks (XSRF), cross-site scripting (XSS) and database query injection.
Incident management & response
In the event of a security breach, we will notify you of unauthorized access to your data. Trelica has specific response policies and procedures in place to handle such an event.
Types of data processed by Trelica
It's important to understand the sorts of data stored and processed by Trelica in order to make an effective security and privacy risk assessment.
These data types are commonly (but not necessarily) stored in Trelica.
Admin users can create their own questionnaires which will contain user entered responses
Credentials for accessing third-party applications
In order to understand usage and for de/provisioning operations Trelica connects to third-party applications. Trelica may store OAuth2 refresh tokens, API keys, or other credentials. The mechanism used depends on the application that Trelica is connected to.