Security Practices
Effective Date: 9th May 2023
Last updated
Effective Date: 9th May 2023
Last updated
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.
Please contact compliance@trelica.com if you need a copy of our SOC2 report.
Users are authenticated using one of:
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 and OVH Cloud platforms, which provides a secure, fault-tolerant environment with hosting options in the US or Germany (the latter being particularly approriate for customers who require data to be held within the EU). Development and Pre-production environments are completely segregated. Azure and OVH data centers maintain multiple certifications including ISO 27001, 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.
IP tables and Azure Network Security Groups are used to define inbound and outbound security rules. The Trelica platform runs on Kubernetes using NGINX as an ingress controller. Suricata is used for Intrustion Detection.
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.
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.
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.
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.
Data Type
Detail
User identities
Name, Email, Job role, Team, Location, Start date, Termination date, Cost Center
Activity data
Last login or other activity dates for users
Audit logs
Details of actions performed by users
Software license data
Licence term, pricing, contract documents
Software spend data
Amounts spent on software
Responses to assessment questionnaires
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.
