security and assurance

How getax protects a client’s data.

A firm entrusts getax with the facts of a client’s affairs. This page sets out where that data goes, how it is protected at each step, which services touch it, how a client’s rights are honoured, and what your risk committee receives in writing before a pilot.

architecture

Where a client's answers go.

A client fills in the questionnaire in a browser on your firm’s subdomain. Everything after that runs on infrastructure getax controls in the European Union. One step calls out: the model call that drafts the report, and it goes through a gateway with zero data retention enabled.

Teal marks a stage whose contents are encrypted at rest. The dashed purple box is the one external call, and the dotted outline is getax’s own infrastructure.

Read the data flow as text

The client answers the questionnaire in a browser, on your firm’s subdomain.
Intake stores the draft as an encrypted token, so a partly finished questionnaire is already ciphertext.
The completed answers become an encrypted profile in the database.
Analysis builds a prompt from validated facts and the profile, and sends it through the gateway to the model provider with zero data retention enabled. This is the only external call. The draft comes back the same way.
The result is written to an immutable report snapshot. The profile inside it stays encrypted.
Your firm’s reviewer inspects the draft in the console: opens the evidence behind any sentence, refines it with an instruction, and downloads the PDF, which carries your firm’s name. Every version is kept.

Encrypted at rest, field by field.: The tax profile, the questionnaire draft, the chat thread on a report, staff review notes, regeneration instructions and a firm's stored SSO client secret are each held as an encrypted token in the database. A database read of those columns returns ciphertext.
Readable only where sign-in needs it.: Account email addresses and display names, the client name and email on a client record, and the delivered report's prose are stored as written, because sign-in and client lookup need them readable. Everything a client discloses about their affairs sits behind the encryption above.
Tenant isolation on every request.: Every route resolves the caller's firm before it reads anything. A request for another firm's report, client record or export is refused, and that behaviour is covered by the automated tests that gate every release.
Separate production and development.: Separate databases, separate secrets and separate hosts, pinned per hostname at the edge. Development never reads production data.
Hosted in the European Union.: Client data at rest stays inside the EU. Every connection, from the client's browser to the firm's console to the one external model call, is encrypted in transit.
Record ids in logs, audit entries and URLs.: An audit row records who changed which field, and when, and withholds the value. Personal data does not appear in logs, error reports or URLs.
Support access is time-limited and attributed.: When getax staff open a firm's workspace to help, the session expires on its own and every entry it writes carries the staff member's own identity, so the audit trail always says who acted.

access and retention

Who can sign in, and what is kept.

Identity and sign-in

Per-firm OIDC single sign-on: Three provisioning modes. Invite: an administrator creates the account and the provider authenticates it. Auto: an account is created on first login for the email domains you list. Groups: your provider’s group claims set the role at every login, with a guard that stops it demoting your last administrator. Turning on require-SSO closes every other route in, including sign-in links already issued, and your identity provider’s multi-factor policy then applies to every sign-in.
Sign-in links: The secret in a sign-in link never reaches the database. Only its hash is stored, so a database read cannot mint a login. A client’s link burns on use. A console link expires, on a schedule your firm sets, and requests for links are rate-limited per address and per firm.
Seats and sessions: Your seat limit is set with getax. An invite or a first SSO login beyond it is refused. Sessions are signed; disabling a user revokes every live session at once.
The client link: Your client reaches the questionnaire, and later their report, through a link on your firm’s subdomain. It resolves nowhere else, and report content behind it requires a signed-in session belonging to the report’s owner.

GDPR export and erasure

Export returns: Reports, questionnaire drafts, client-record history and session recordings, for a data subject your firm administers. Every export is audited.
Erasure removes: The encrypted profile and the prose on every report snapshot in the lineage, staff review notes, regeneration instructions, questionnaire drafts, client-record revisions, the profile held behind an unapproved jurisdiction, session recordings and the model trace for each erased report. The account itself is anonymised and its sessions revoked.
Erasure preserves: The provenance chain on each report snapshot: its id and date, the fact versions it used, the source documents behind them, the claim list and the model and prompt versions. Those columns carry no personal data, and they are what a citation in a delivered report resolves through, so a firm can still show why a delivered position said what it said.

Retention

A per-country policy sets the lifetimes: ten years for reports and report chats, against tax record-keeping obligations, and thirty days before an abandoned questionnaire draft is anonymised. Final deletion is always a deliberate, audited action, never a silent side effect.

Session recording

The client questionnaire records a session replay only after the client consents, and the consent text says so. Every input on that surface is masked. Recordings are held on getax infrastructure under a thirty-day retention policy, and only a getax operator can play one back.

controls

The controls, and how each one is evidenced.

Every row runs in the product today. The third column says how your reviewers can see it for themselves: in a demo, in the automated tests that gate each release, or in the written pack issued before a pilot.

Control areas, what runs today, and how each one is evidenced to a reviewer.
Control	What runs today	How you can see it
Tenant isolation	Every route resolves the caller's firm before it reads; cross-firm reports, records and exports are refused	The automated test suite gates every release; shown live in a demo
Client data encrypted at rest	Field-level encryption on profiles, questionnaire drafts, chat threads, review notes, regeneration instructions and stored SSO secrets	Schema walkthrough and a ciphertext read, on request
Encrypted in transit	TLS on every connection: client browser, firm console, model gateway and email	Observable from any browser; certificate details on request
Environment separation	Production and development on separate databases, secrets and hosts, pinned per hostname at the edge	Edge configuration is checked by an automated test on every release
Single sign-on	Per-firm OIDC with three provisioning modes, require-SSO, and seat limits	Configured together during onboarding against your identity provider
Sign-in links	Hashed at rest, expiring, burn-on-use for clients, rate-limited per address and per firm	Automated tests on every release
Audit trail	Attributed, timestamped client-record revisions with revert; entries hold ids and field names, never values	Visible to your administrators in the console
Support access	Time-limited, attributed to the individual getax staff member, and written to your audit trail	Visible to your administrators in the console
GDPR export and erasure	Endpoints for both, scoped per data subject, audited, with the report's provenance chain preserved and model traces deleted	Automated tests on every release; exercised in a demo on a test client
Consent at intake	Versioned, server-timestamped and audited before any answer is kept	Visible on the client questionnaire
Approved-jurisdiction controls	Report generation is limited to the jurisdictions approved for your firm; a profile beyond that list is held encrypted until the jurisdiction is approved and the report is generated	Shown live in a demo
Model-provider data handling	Zero data retention is enabled on the gateway account; the fact-base pipeline never sees client data	Written confirmation before a pilot; contract terms on request
Session recording	Consent-gated and input-masked, thirty-day retention policy, operator-only playback	Visible in the consent text on the client questionnaire

Scroll the table sideways for the remaining columns.

Your own security questionnaire is answered in writing, with the underlying evidence, before a pilot begins.

the model call

What the model provider receives.

One step in the data flow leaves getax’s infrastructure: the model call that drafts the report. This is what it carries, where it goes, and on what terms.

What is sent.: For each draft: the validated facts selected for the client's profile, the profile's disclosed facts, and the drafting instructions. The pipeline that builds the fact base never transmits client data.
The route.: A model gateway, OpenRouter, forwards the request to the upstream model provider, Anthropic by default, with zero data retention enabled on the gateway account. A firm can ask for its engagements to be pinned to a specific provider and model.
Training.: No client data is used to train any model, by getax or by the providers under those terms.
Locations.: getax infrastructure is in the European Union; the gateway and the upstream provider process the request in the United States under the standard contractual clauses in the data-processing agreement.
The trace.: Each draft's model trace is kept on getax infrastructure, visible to getax operators only, and deleted when a client is erased.

pilot

How to evaluate getax without exposing a client.

The evaluation that tells you something runs in shadow mode, on matters your firm has already closed, and it is measured against your own reviewers.

The shadow pilot runs on twenty or more closed files, with no client involved: your staff enter the facts, your reviewers score each draft on four axes, and the go/no-go is held with your risk partner, your DPO and your information-security lead. The seven steps, what you receive and what we need from you are on the pilot page.

Discuss a shadow pilot How a shadow pilot runs