Security

1Our approach

Security controls here are enforced by the software, not by policy alone. Where a protection can be made structural — a permission we never request, a database rule that cannot be bypassed by application code — we prefer that to a rule someone has to remember to follow.

Truseta completed a full-scope security review in August 2026 covering authentication, multi-tenant isolation, every API route, database access rules, webhooks and scheduled jobs, third-party authorisation, AI tool access, and dependency handling, assessed against a written threat model. Findings are graded by severity, assigned to a named owner, and verified in staging before release.

2Tenant isolation

Every workspace is isolated at the database layer, not only in application code. Access rules are enforced by the database itself on every table, so a defect in an API route cannot expose another client's data. Enabling those rules is a mandatory condition of creating any new table.

Within a workspace, collaborators receive per-area permissions — none, view, or edit — across wealth, private equity, entities, estate, documents and administration. Reads, writes, navigation and interface are all governed by the same grid. Connecting credentials and managing users are reserved to the workspace owner.

3Authentication

Accounts cannot self-provision; access is by invitation or approved application. Password sign-in requires a second factor from an authenticator app, and an account with no enrolled factor is routed into enrolment before it can reach the application. Federated sign-in through Google inherits the multi-factor policy enforced at Google.

These checks run in middleware ahead of every API route, so enforcement does not depend on any individual route being written correctly. Sessions expire daily on desktop and every seven days on registered iOS devices.

4Encryption

• All traffic is encrypted in transit with TLS 1.3. No unencrypted transport is permitted.
• All stored data is encrypted at rest with AES-256.
• Sensitive fields — aggregator tokens, third-party authorisations, tax identifiers, account numbers — carry an additional layer of encryption using per-client derived keys, so one client’s data cannot be decrypted with another client’s key.
• Encryption keys are held in a dedicated secrets vault, separate from the application database, and are never exposed to code running in your browser.

5What we will not do

We never send email from your account. This is structural: Truseta does not request the Google permission that would allow it, and no part of the application can reach an endpoint that sends mail on your behalf. Anything the assistant composes for you is placed in your own drafts, for you to read and send yourself.

Your documents stay in your Drive. Documents you link from Google Drive are read using your own authorisation and are not copied onto Truseta servers. Documents you upload against a legal entity are written into your own Drive folder, not ours.

We do not sell your data, advertise against it, or train generalised AI models on it. Human access is limited to what you authorise, what security or law requires, and what is needed to operate features you are using.

6Logging and monitoring

Security-relevant events — authentication, integration connection and disconnection, administrative changes, and access to client data by Truseta personnel — are written to an append-only audit log. Runtime errors are captured in a third-party monitoring platform with alerting and reviewed daily. Publicly reachable endpoints are rate limited per source address.

7Secure development

Every change deploys first to an isolated staging environment. Production changes happen only by explicit promotion of a verified staging build; direct deployment to production from source control is disabled. Every release is recorded with its version, date, contents, and the named person who authorised it.

Destructive schema or data operations require explicit human authorisation, and no change reaches production without passing static type checking and a production build.

8Vulnerability management

Third-party dependencies are scanned automatically, with alerting on newly disclosed vulnerabilities and automated remediation. Identified issues are remediated on a defined schedule measured from disclosure: critical within 7 days, high within 30, medium within 90.

Truseta is undergoing independent assessment under the Google Cloud Application Security Assessment programme, which evaluates applications against the OWASP Application Security Verification Standard.

9Your control over your data

• You can revoke Truseta’s access to any connected provider at any time. Revocation takes effect with that provider immediately and deletes the stored authorisation.
• You can export a complete archive of your workspace at any time, without contacting us.
• You can request deletion of your account and data from Settings. We confirm the request with you before anything is removed — deleting a family office’s records is not something we make a one-click action.
• On closure, personal data is deleted within 30 days, and from encrypted backups within 90.

The Privacy Policy sets out in full what we collect, why, and who it is shared with.

10Reporting a vulnerability

If you believe you have found a security vulnerability in Truseta, write to security@truseta.com. Please include enough detail to reproduce the issue. We will acknowledge your report, keep you updated as we investigate, and will not pursue action against good-faith research that avoids privacy violations, data destruction, and service disruption.

If you suspect your own account has been compromised, contact the same address immediately.