SECURITY

Where records live, and who can change them.

Records and files in London, application servers in London, each workspace isolated by database rules, every file virus-checked, and every material change written to an append-only audit trail.

Book a 30-minute call Read the privacy policy

Database records: Google Cloud Firestore, London (europe-west2)
Uploaded files: Google Cloud Storage, London (europe-west2)
Application servers: Vercel, London (lhr1)
Virus checking: Every file and every version the checker can examine, before it is downloaded, extracted or released, by a scanner in Google Cloud Run, London (europe-west2); an infected file is refused; a file it cannot examine, over 50 MB or a type it does not read, says so on screen instead of pretending
Backups: Daily export to a London bucket, kept 30 days; point-in-time recovery for the past seven days
In transit: TLS; HTTPS only, with HSTS
At rest: Platform encryption; authenticated AES-256-GCM on authenticator seeds
Sign-in: Two-factor authentication required for every user on every plan
Sign-in methods: Email and password, Google or Microsoft on every plan; SCIM provisioning from your identity provider on Enterprise
Isolation: Database rules check membership and role on every read and write, so a bug in the application cannot read another workspace: the database refuses
Audit: Append-only trail for appointments, ownership, statutory data and documents
Second person: Entity deletion, funds-flow release and structure-chart sign-off
AI: Proposes only; workspace data is not used to train third-party models or sent to translation tooling
Your data: Exportable at any time while the account is active; the developer API is included on Enterprise

A KYC requirement with its proposed response and the record field it was drawn from — Requirement 2, “Provide the registration number”: the proposed response B-249004 is drawn from the record’s registration-number field, and evidence can be attached to the answer.

EVIDENCE

Evidence stays attached to the answer.

A KYC response carries its source: the record field it was drawn from, or a document attached as evidence. Approving an answer keeps that link; a reviewer can request information instead of approving.

ISOLATION

Isolation is enforced in the database.

Access to workspace content is governed by database security rules that check membership and role on every read and write, so isolation does not depend on application code alone, and that boundary is covered by an automated test suite. Server-side requests verify the caller’s identity on every call and honour session revocation, so removing someone’s access takes effect immediately.

The currency, signing rule, approver, review and control columns of the bank accounts table — The right-hand columns of the bank accounts table, one row per account: currency, signing rule, approvers, review due and control findings. The last row: a euro account, any one signatory up to €100,000, two approvers, review due 31 March 2026, three findings.(1) 3 findings on that account

BANK DETAILS

Checked against evidence; any edit drops the check.

Bank account details carry an evidence-backed verification stamp that any edit to the routing fields removes. Each account shows its signing rule, approvers, review date and control findings, so a missing approver or an overdue review is visible on the register itself.

WHAT WE DO

Encrypt in transit and at rest
TLS on every connection; platform encryption at rest; AES-256-GCM on authenticator seeds.
Check every file for viruses
Every file and version it can examine, before download, AI extraction or release, older versions included; a file it cannot examine, over 50 MB or a type it does not read, says so on screen instead of pretending.
Back up daily
A daily export to a London bucket, kept 30 days.
Write material changes to an append-only audit trail
Appointments, ownership, statutory data and documents.
Require a second person
For entity deletion, funds-flow release and structure-chart sign-off.
Check membership and role on every read and write
In the database’s own security rules.

WHAT WE DO NOT DO

Train models on your data
Workspace data is not used to train third-party models.
Send tenant data to translation tooling
Never.
Let AI write to a record on its own
AI proposes; a person approves.
Store records or files outside London
Database records and uploaded files in Google Cloud europe-west2; application servers in Vercel lhr1.

CERTIFICATIONS

What we do not hold yet, and what an auditor is shown instead.

Alethia does not yet hold a SOC 2 or ISO 27001 certificate. What an auditor is shown instead: the database rules and the automated suite that proves them on every change, the append-only audit trail, the daily export, and this page, which says only what the product enforces. Security questionnaires are answered before purchase.

SUB-PROCESSORS

Who else touches the service.

Every third party that receives customer or visitor data, what it receives, where, and when. A row that starts with Only is off until the setting it names is switched on.

Google Cloud (Firebase): Database (Firestore), file storage (Cloud Storage), sign-in accounts (Firebase Authentication) and the virus scanner that checks every uploaded file (Cloud Run). Receives: All workspace records and files, and account details. Where: London (europe-west2) for the database, files and virus scanner; Firebase Authentication is a global Google service. Always in use.
Vercel: Runs the application and the public website, and its scheduled jobs. Receives: Requests and responses passing through the application, and request logs. Where: London (lhr1) for application servers; its content delivery network serves pages worldwide. Always in use.
Postmark: Sends email: invitations, sign-up notices, KYC requests and reminders, digests and scheduled reports. Receives: Recipient email addresses and names, the message content and any attached report. Where: Provider's own infrastructure; not pinned by Alethia. Only if outbound email is configured with Postmark.
Resend: Sends the same email as Postmark, as the fallback provider. Receives: Recipient email addresses and names, the message content and any attached report. Where: Provider's own infrastructure; not pinned by Alethia. Only if outbound email is configured with Resend and not with Postmark.
Stripe: Invoices, payments and the billing portal. Receives: Billing contact, plan and invoice amounts; card details are entered on Stripe's own pages and never reach Alethia. Where: Provider's own infrastructure; not pinned by Alethia. Only if billing is connected to Stripe.
Anthropic: AI document extraction, search and drafting (proposals a person reviews). Receives: The document or text a user submits and the prompt; not used to train models. Where: Provider's own infrastructure; not pinned by Alethia. Only when AI is switched on for the workspace by its administrator, and a person asks for an AI proposal.
OpenAI: AI search and drafting (proposals a person reviews). Receives: The text a user submits and the prompt; not used to train models. Where: Provider's own infrastructure; not pinned by Alethia. Only when AI is switched on for the workspace and Alethia has chosen OpenAI as its AI provider; document extraction never goes to OpenAI.
Google (Gemini API): AI search and drafting (proposals a person reviews). Receives: The text a user submits and the prompt; not used to train models. Where: Provider's own infrastructure; not pinned by Alethia. Only when AI is switched on for the workspace and Alethia has chosen Google as its AI provider; document extraction never goes to Google.
Google reCAPTCHA (Firebase App Check): Checks that requests come from the real application and not a script. Receives: Browser and device signals from the person using the application. Where: Provider's own infrastructure; not pinned by Alethia. Only if App Check is switched on for the application.
Companies House: Looks up UK company details, officers and filings. Receives: The company name or number being looked up. Where: United Kingdom. Only if the Companies House lookup is configured, and a user looks a company up.
GLEIF (Global Legal Entity Identifier Foundation): Looks up Legal Entity Identifiers, the entity details GLEIF holds and the parents reported to it. Receives: The LEI or the entity name being looked up. Where: Provider's own infrastructure; not pinned by Alethia. Only when a user looks up an LEI, or searches GLEIF for an entity by name.
postcodes.io: Turns UK postcodes into addresses and map positions for deal sites. Receives: The UK postcode being looked up. Where: Provider's own infrastructure; not pinned by Alethia. Always in use.
Ideal Postcodes: Lists street addresses for a UK postcode on the deal form. Receives: The UK postcode being looked up. Where: Provider's own infrastructure; not pinned by Alethia. Only if the street-address lookup is configured.
Photon (komoot): Places deal sites on the pipeline map when they have no postcode. Receives: The place name entered for a deal site. Where: Provider's own infrastructure; not pinned by Alethia. Always in use.
OpenStreetMap: Map tiles for the pipeline map. Receives: The viewer's IP address and the map area in view, requested by the browser. Where: Provider's own infrastructure; not pinned by Alethia. Always in use.
Slack: Posts the alerts the workspace chooses to a Slack channel. Receives: The alert text: compliance, sign-off and registry notices. Where: Provider's own infrastructure; not pinned by Alethia. Only if a workspace administrator connects Slack.
Asana: Copies deal tasks, milestones and obligations into Asana. Receives: Deal names, task and obligation titles, and due dates. Where: Provider's own infrastructure; not pinned by Alethia. Only if a workspace administrator on Enterprise connects Asana.
OpenSign, DocuSign or Adobe Acrobat Sign: Sends documents and structure charts for electronic signature. Receives: The document to be signed, and the signers' names and email addresses. Where: Provider's own infrastructure; not pinned by Alethia. Only if electronic signature is switched on, and then only the one provider configured.
Calendly: The booking calendar on the book-a-call page. Receives: The booking details the visitor enters, and Calendly's own cookies. Where: Provider's own infrastructure; not pinned by Alethia. Only if the visitor chooses Accept all, or presses Load the calendar on the booking page (that visit only), on the public website only.
Microsoft Clarity: Aggregate heatmaps and session insights for the public website. Receives: How visitors use the website pages, and its cookies. Where: Provider's own infrastructure; not pinned by Alethia. Only if the visitor chooses Accept all, on the public website only.
Google Analytics and Google Ads: Aggregate visit statistics, and whether a booking followed an advert. Receives: Website page visits and traffic sources, and their cookies. Where: Provider's own infrastructure; not pinned by Alethia. Only if the visitor chooses Accept all, on the public website only.
tawk.to: Live chat on the public website. Receives: The chat messages and any details the visitor types, and its cookies. Where: Provider's own infrastructure; not pinned by Alethia. Only if the visitor chooses Accept all, on the public website only.

QUESTIONS

Stored records and stored files stay in the London region. Data leaves it only to the providers listed above, for the purposes and at the times shown, and each receives only what its service needs. Where any of them processes limited personal details outside the UK or EEA, it is under standard data-protection safeguards. The legal detail is in our Privacy Policy.

We process personal data in line with UK and EU data-protection law. Customers can request a data-processing agreement, and enquiries, including security questionnaires, are welcome ahead of a purchase.

Send us your security questionnaire.

We answer questionnaires, provide a data-processing agreement and walk your IT team through residency and access control before purchase.

Book a 30-minute call Read the privacy policy