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, and names the providers that process client data.
Where records are held
Assettia runs on a managed cloud platform: the database, file storage and server functions are provided through Lovable Cloud on Supabase, hosted on Amazon Web Services in the Ireland (eu-west-1) region. Client records do not leave that region in normal operation.
Encryption
Connections to the platform are encrypted in transit using TLS. Records and files are encrypted at rest by the hosting platform.
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. Every such table has these rules switched on; none is exempt. There is no application path that reaches a record without passing them. 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. There is no self-service sign-up: an administrator creates each account and issues a temporary credential that expires. 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. Sign-in is rate-limited with a progressive lockout, and two-factor authentication is available. Sensitive actions are written to an audit log: account creation and removal, role changes, exports, archiving, branding changes and sign-in lockouts. Administrators can read the log.
Backups
Records are backed up daily. Restores are tested on a stated schedule, and the date of the most recent restore test is available on request.
How AI is used, and where it is not
Models are used to draft: a summary, a suggested risk, a proposed classification, a first version of a policy section. 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.
Model requests are routed through a gateway to Google (Gemini models) and Anthropic (Claude models). The content sent is the client business content the feature is working on: interview transcripts, strategy documents, use case descriptions, assessment responses, survey text. Client data is not used to train any model, under the providers' business terms.
Who processes client data
A sub-processor register is maintained. The providers that process client data are: Lovable (hosting platform and AI gateway); Supabase and Amazon Web Services (database, storage and functions); Google and Anthropic (model providers, as above); Firecrawl (fetches public web pages for market and evidence research; receives no client records); Resend (sends invitation and notification emails; receives names and email addresses). The website separately uses Plausible for analytics, which sets no cookies, and the hosting platform's own page-view analytics.
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.
Independent testing
No certification is claimed. Independent security testing is scheduled, and its results will be summarised here when complete.
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.