Security Statement

1. Purpose

This Security Statement describes the technical and organisational measures TRM Flex Limited applies to protect the confidentiality, integrity and availability of personal data and customer data on the TRM Flex platform. It supports our obligations under Article 32 of the UK GDPR and the Data Protection Act 2018.

This page is written in plain English and is updated when material changes are made. It is not an exhaustive technical specification; controls may evolve as threats and best practice change.

2. Hosting and infrastructure

The platform is hosted on Vercel's managed edge infrastructure, with the application database and file storage on Supabase (managed PostgreSQL) in the United Kingdom (London), where platform personal data is primarily processed.
The application database is PostgreSQL with row-level security policies enforcing tenant isolation.
Edge functions and API endpoints run in a managed serverless runtime with automatic horizontal scaling.
Static assets are served via a global content delivery network with TLS termination at the edge.

3. Encryption

In transit: All client-facing traffic is encrypted using TLS 1.2 or higher. HTTP requests are redirected to HTTPS.
At rest: The application database, file storage and backups are encrypted at rest using AES-256.
Secrets: API keys, integration credentials and signing keys are stored in a managed secret store, never in source code, and are rotated when staff with access leave.

4. Access control

Customer access is authenticated via email and password or, where enabled, third-party identity providers. Passwords are hashed using a modern key-derivation function; we never store plaintext passwords.
Sensitive actions (administrative changes, data exports, financial actions) are logged server-side with the actor, action and timestamp.
Application roles (Worker, Client, Admin, Super Admin) are enforced backend-first; frontend role checks are secondary and not relied upon for security.
Internal staff access to production data is limited to named individuals on the principle of least privilege, requires multi-factor authentication and is audit-logged.

5. Tenant isolation

Multi-tenant data is isolated at the database layer using row-level security policies that scope every read and write to the authenticated user's organisation. These policies are audited and any changes are reviewed before deployment.

6. Application security

Common web application risks (OWASP Top 10) are mitigated through a combination of input validation, parameterised database access, output encoding, content security policy headers, and use of established libraries.
An AI-prompt guard layer is applied to AI edge functions to mitigate prompt injection and unsafe output, with prompts and outputs sanitised before use.
Rate limiting and abuse detection are applied to public and authenticated endpoints to mitigate brute force and scraping.

7. Vulnerability management

Dependencies are scanned automatically and high-severity vulnerabilities are triaged for remediation.
An internal security audit was completed in March 2026.
An independent external penetration test against the production environment is planned and has not yet been carried out. We do not claim CREST, ISO 27001 or SOC 2 certification at this time.
Critical patches are applied as soon as practicable; non-critical patches are bundled into regular release cycles.

8. Incident response

We operate a documented incident response process covering detection, triage, containment, eradication, recovery and post-incident review.
Where an incident involves a personal data breach, we will notify affected customer controllers without undue delay and in any event within 72 hours of becoming aware, in line with UK GDPR Art. 33 and our Data Processing Addendum.
Where required, we will notify the Information Commissioner's Office (ICO) within 72 hours under our registration ZC121365.
An S1 post-incident review is published to affected customers within 10 business days of resolution.

9. Backups and recovery

The production database is backed up daily with a minimum 7-day rolling restore window.
Backups are encrypted at rest and tested via periodic restore exercises.
Recovery objectives are reviewed at least annually.

10. Sub-processors and third parties

We use a small number of vetted third-party sub-processors to deliver the platform. Each is covered by a Data Processing Agreement where personal data is involved. The current list is published at /sub-processors.

11. People and process

Staff and contractors with access to production sign confidentiality undertakings.
Security training is delivered at onboarding and at least annually.
Right-to-work, identity and reference checks are completed for staff handling personal data.
Access is revoked immediately when a person leaves or changes role.

12. Reporting a vulnerability

We welcome responsible disclosure. If you believe you have found a security vulnerability, please email hello@trmflex.com with subject prefix [Security]. Please:

give us a reasonable time to investigate and remediate before any public disclosure;
do not access, modify or delete data that does not belong to you;
do not perform denial-of-service or resource-exhaustion testing;
act in good faith and in accordance with the Computer Misuse Act 1990.

We will acknowledge legitimate reports within 2 business days and keep you informed of progress. We do not currently operate a paid bug bounty.

13. What we do not claim

In line with our commitment to factual statements:

We do not currently hold ISO/IEC 27001 certification.
We do not currently hold SOC 2 (Type I or Type II) attestation.
We have not yet completed an independent CREST-aligned external penetration test (planned).

When any of these change, this page will be updated and the change will be communicated to active customers.

14. Changes

We may update this Statement to reflect changes to controls, regulation or best practice. The “Last updated” date at the top of this page reflects the most recent change.