Security
What is separated from what, and how
Written the way we would want to read somebody else's: specific about the boundary, specific about how it is enforced, and specific about the limits.
The questions a security review opens with
Answered here rather than six sections down, and short enough to paste into a questionnaire.
- Can another customer see our data?
- No. Which workspace you are acting in is re-derived from a live membership row on every request, above every other permission check, and a request naming something in another workspace is answered as though it does not exist. The rule is enforced by a check that runs in our build and fails it — not by every developer remembering.
- Can your staff read our messages?
- Technically yes, and we would rather say so than imply otherwise. Truostray is not end-to-end encrypted. We access content only where operating, securing or supporting the service requires it — that is a commitment in the terms rather than a technical impossibility, and we will not dress it as one.
- Is our data encrypted?
- Documents, form answers and signature images are encrypted by the application, each with its own AES-256-GCM data key wrapped by a master key. Message bodies are not, and rely on encryption of the underlying storage plus retention. In transit, over TLS: the service sets HSTS on every response, and its session cookie is marked Secure in every deployment that is not a developer’s laptop.
- Where is it stored?
- In the regions a given deployment is configured for, which we will state in writing. If your data has to stay in a particular country, ask before you commit: a single-tenant deployment in a region you choose is something we can discuss, and not something the shared service can promise.
- Do you train AI models on our data?
- No — not our models and not anybody else’s. We do not sell it, share it for advertising, or use it for anything but running the service for you.
- Who can see what, inside our own organisation?
- Permission attaches to a seat in your org chart rather than to a person, and a document is readable by the people the thing it is attached to was shared with — checked per file, not inherited from a folder. Your administrators set the rest.
- Can we prove who did what?
- Yes. Every security- and approval-relevant action writes an append-only record: the actor, the action, the thing acted on, the time, the address, the device, and for a change the field values on both sides of it. Nothing in the product updates or deletes one, and you can take the whole trail away as CSV.
- What happens when somebody leaves?
- Erasure removes their name, email, phone, avatar, sessions, devices, private approval phrases and signature images, and keeps their identifier so the approvals they made still resolve. It cannot recall copies already taken, and we say so rather than implying a clean slate.
- Can we get our data out?
- The audit trail exports itself as CSV. Messages, requests and documents we extract for you by hand on request, in formats you can read without us. We would rather tell you that than call a manual process a button.
- What happens if there is a breach?
- We notify your administrators without undue delay, with what we know, what we have done, and what you should do. The commitment and the deadline are in the privacy policy rather than in a sentence on a marketing page.
One workspace cannot see another
Separation is the foundation everything below rests on. It is not a filter applied to a query somewhere; it is re-derived from your membership on every request, and a request that reaches across it is answered as though the thing on the other side were not there.
The rule is checked mechanically rather than remembered: a boundary that depends on every developer recalling it is a boundary that lasts until the busiest week of the year.
A document is readable by the people it was shared with
Not only by whoever uploaded it, and not by anybody who ends up holding the link. Access follows what the file is attached to, and the file carries its own history: who uploaded it, what changed, and every decision taken on the request it supports.
Encrypted with a key of its own, scanned on upload, served through the gateway.
In detail
Arranged under the headings a security questionnaire uses, so the answer is where you expect it to be.
Authentication and access control
Membership is the boundary, not the account. Which workspace you are acting in is re-read from a live row on every request, so removing somebody takes effect on their next request rather than whenever a token happens to expire.
A request naming something in another workspace is answered as if it does not exist — the same answer as a missing id, so an identifier cannot be used to probe for what exists elsewhere.
Passwords are stored with scrypt and a salt each, refresh tokens only as hashes, and the plaintext never leaves your device. Sign-in is rate limited, cross-site writes are refused, and the service will not boot in production on a missing or example signing key.
Role-based permissions
Permission attaches to a seat in the org chart rather than to a person, so a transfer moves the authority with the post and a vacancy is visible instead of silent.
Approval steps are assigned to seats or units, with quorum, escalation and delegation while somebody is away. Nobody approves their own request: it is enforced at the moment of the decision, not assumed when the flow was drawn.
Secure document access
A file is readable by the people it was shared with, not only by whoever uploaded it. Access follows what the file is attached to — the conversation, the request, the task — and is checked per file rather than inherited from a folder.
Each document is encrypted with its own data key, and that key is itself encrypted by a master key held by the gateway — so rotating the master key re-wraps one row per document instead of rewriting every byte you own. AES-256-GCM, so a tampered file fails to decrypt rather than returning plausible rubbish.
Downloads are issued as short-lived signed links rather than from a storage path somebody could guess or forward indefinitely. Form answers and signature images are sealed the same way, with a key each.
Session management
The browser holds a session id in an httpOnly cookie and never a token a script could read.
Refresh is one-use. Presenting a refresh token that has already been spent revokes every session for that account, because at that moment a thief and the owner are indistinguishable. Each session records its address and device, and any one of them can be ended from the others.
Auditability
Who did what, to which thing, from which address and on which device — and, for a change, the fields that moved, on both sides of the change.
The trail is append-only: nothing in the product updates or deletes an audit row, and a decision keeps its record after the person who made it has gone. Filter it and take the result away as CSV, so "send me last quarter" is answered with a spreadsheet rather than a cursor to walk.
Data protection
Documents, form answers and signature images are encrypted by the application, each with its own key. Message bodies are not — sealing them would end message search — so what protects those is volume encryption underneath and retention above: a per-conversation policy and an hourly purge that deletes old messages rather than keeping them forever.
A person can be erased without erasing the decisions they made. Name, email, phone, avatar, sessions, devices and signature images go; the id stays as a pseudonym so the approval chain still resolves. It cannot restore copies already taken: anyone who read a document before the erasure still holds it, and the trail still records that somebody — now unnamed — approved a particular thing on a particular day.
What Truostray does not currently provide
Stated because a security page without this section is an advertisement. Each of these is a real gap today, not a feature described carefully.
Not end-to-end encrypted, and message bodies are not sealed by the application. The server can read them, which is what makes search, notifications and compliance export possible. If you need a channel we cannot read, this is not that product.
What protects them instead: encryption of the underlying storage, retention policies that delete old messages rather than keeping them forever, and the fact that transcripts are never written to disk on either client. The things a form is most likely to hold — an identity number, a salary, a home address — are sealed with a key each, because nothing searches them and sealing costs no feature.
No malware scanning. Uploads are stored and served as they arrive. Nothing inspects a file for malicious content before somebody in your organisation opens it.
What limits the blast radius: a file is reachable only by the people the thing it is attached to was shared with, never from a guessable storage path, and only through a signed link that expires. A malicious upload can reach the people already in that conversation; it cannot reach the workspace, and it cannot reach another organisation.
No multi-factor authentication yet. Deliberately left for federation with an identity provider rather than built as a local second factor. If you need it before federation, say so and we will tell you honestly where it sits.
What stands in for it: passwords are stored with scrypt and a salt each; sign-in is rate limited to ten attempts a minute; refresh is one-use, so a stolen session token revokes every session for that account the moment the real owner uses theirs; and every session shows its address and device so a stranger is visible and can be ended.
No step-up authentication. Nothing asks for a password again immediately before a sensitive action. A live session can do everything that session is permitted to do.
What narrows it: permission is granted by seat rather than by person, so a session can only ever do what that post is entitled to do; approving requires a signature that belongs to the approver; and every sensitive action lands in an append-only trail with the address and device it came from.
No customer-managed encryption keys. Documents are encrypted with keys we hold and rotate. You cannot supply or revoke your own key today.
What the design gives you anyway: every document has a data key of its own, wrapped by the master key, so rotating the master re-wraps one row per document rather than rewriting every byte you own — and a single-tenant deployment with your own key material is a conversation we can have.
Only the audit trail exports today. You can take the trail away as CSV whenever you like. A full export of messages, requests and documents is something we do by hand on request; it is not yet a button you press.
What that means in practice: you are not locked in. Ask and you get your data, in formats you can read without us, within the window the terms commit to.
Infrastructure is assumed, not verified by the application. TLS termination, volume encryption, storage bucket policy, network segmentation and backup handling are configured by whoever runs the deployment. Nothing in the application checks them, and the statement above about message bodies leans directly on volume encryption being real.
What we will do: tell you exactly how a given deployment is configured, in writing, and let your own team verify it. For a single-tenant deployment, that team can be yours.
Not independently audited. There is no third-party penetration test or certification to point at. If that is a requirement for you, tell us and we will talk about a timeline rather than show you a badge.
What we do instead, today: the workspace boundary is enforced by a check that runs in the build and fails it, rather than by everybody remembering — and known-vulnerable dependencies fail the build too. Neither is a substitute for an external audit, and we are not offering them as one.
Found something this page does not cover? Tell us and we will answer specifically, including when the answer is no.
Questions a page cannot answer
Send them to us and we will answer them specifically.