How client records are kept
Assettia is the data and AI programme record: one place where an organisation keeps what its programme owns, what it has decided, and what it has proved.
A programme record holds decisions, risks and evidence that a board relies on. This page sets out how that record is protected, in plain terms. It states what is in place today. Where a detail has not yet been confirmed for publication, it says so rather than leaving the reader to assume.
One record per organisation
Each client organisation's records are held in their own tenant. Access to any record is decided by rules enforced inside the database itself, on every query, for every table that holds client data. There is no application path that reaches a record without passing those rules. Files and documents are stored under paths that belong to the tenant they came from.
Nothing is deleted
Records are archived, never deleted. A use case, a decision, a risk or a document that is withdrawn is marked as archived and kept, so the history a board has relied on cannot be quietly changed. Released documents are held immutable once released; a later version is a new document, not an edit to the old one.
Who can see what
Access is by named user account, granted by invitation. Each user holds a role that determines which organisation's records they can reach and what they can do with them. Consultants working with a client see that client's tenant and no other. Sensitive actions are written to an audit log.
How AI is used, and where it is not
Models are used to draft: a summary, a suggested risk, a proposed classification. Nothing a model produces writes to a live record. It lands in a reviewable state and becomes a record only when a named person accepts it. Model requests are made from the server, never from the browser, using prompts held in a managed library rather than written into code. Figures shown to executives and boards are computed from records by fixed rules; no model produces a figure.
How changes to the product are controlled
Every change to the product passes automated checks before it can be released, including checks that no client name appears in code or copy, that every displayed count names the population it counts, and that no prompt is embedded in code. Changes are verified on a synthetic organisation before any client sees them. Client data is never used for testing.
Walkthroughs use a synthetic organisation
A prospective client sees the product populated with a synthetic organisation's records. Nothing of the prospect's own is entered until they decide it should be, and then into a tenant of their own.
Still to be published
The following details are confirmed before they appear here. Until then they are listed rather than omitted.
- Hosting provider and data centre region for records and documents.
- Encryption in transit and at rest, and the standards used.
- Backup frequency, retention and the date of the last restore test.
- Sign-in methods available and required: password policy, single sign-on, two-factor authentication.
- The AI providers the platform calls, what is sent to them, and their terms on the use of client data for training.
- The list of third parties that process client data.
- Independent security testing and certification, with dates.
Reporting a concern
Security concerns are received at security@assettia.com and acknowledged by a named member of the team. Responsible disclosure is welcomed.
Ask us anything on this page.
A walkthrough takes forty minutes and uses a synthetic organisation. Security questions can be put to the team on the call or by email first.