Home / Security

Security, written for the people who audit it.

Two versions of the same facts: a plain summary for a business reader, and the technical detail your security team will actually want. Where a control belongs to Google rather than to us, we say so.

The short version

How we protect your data.

Your passwords never touch our systems

Sign-in is handled by Google Firebase Authentication, the identity infrastructure behind thousands of commercial applications. Passwords are verified on Google's servers. We never see them, never transmit them and never store them — so there is no password database in our application for an attacker to steal.

Every action is re-verified, not just the login

Signing in doesn't hand a user a permanent key. Google issues a signed pass that expires roughly every hour, and it travels with every request — opening a screen, running a search, saving a record. Our servers re-check it before the request does anything. Nothing is trusted simply because someone logged in earlier.

Security that stays out of your team's way

The pass renews silently in the background, so staff are never logged out mid-task — and there is no "stay signed in forever" shortcut trading security for convenience.

Documents are handled without a middleman

Files are uploaded and viewed through single-purpose, expiring links issued only to a verified user. Your documents are never left sitting at a guessable web address.

Encrypted in motion and at rest

Traffic between the application and our servers uses TLS 1.3 — the newest version of the standard that secures online banking. We have deliberately switched older versions off. Data at rest on Google Cloud Platform is encrypted automatically; physical access to the storage would yield only unreadable data.

Problems fail safely and quietly

Users see a clear, plain-language message — never internal technical detail. Each request carries a unique tracking reference, so support can trace a specific issue in our logs without asking you to share anything sensitive.

Multi-factor authentication is available and can be enabled for your organisation during onboarding.

For your security team

Authentication and API security architecture.

If a vendor assessment becomes part of your evaluation, we can work through it with you. In the meantime, this is the substance of our security architecture.

Identity provider: Authentication is delegated to Google Firebase Authentication. The application stores no credential material and holds no long-lived secret. Sign-in returns a Firebase-issued ID token — an RS256-signed JWT with a ~1 hour TTL, signed by Google's rotating key set. Refresh tokens are held and rotated by the Firebase SDK.
Token verification: Every inbound API request is authenticated at the backend edge before it reaches application logic. The JWT signature is verified against Google's published public keys, and the iss, aud and exp claims are validated. Requests failing verification are rejected at that boundary; no unverified request reaches business code.
Single client choke point: All outbound API traffic is routed through one client. Authentication is opt-out rather than opt-in and is enabled on every endpoint, so a call cannot accidentally be issued unauthenticated. Each request carries a bearer token and an X-Request-Id built from a timestamp plus 64 CSPRNG bits for end-to-end correlation.
Token lifecycle: The token is requested per call, so SDK-managed caching and silent renewal handle expiry. On a 401 the client performs a single forced refresh and replays the request exactly once. There is no refresh loop and no unbounded retry on authentication failure.
Verb-aware retries: Idempotent reads retry up to twice on 429, 5xx, timeout and socket errors, using exponential backoff (300 / 800 / 1500 ms) with randomised jitter. State-mutating operations — create, update, delete, submit — are explicitly non-retryable and never automatically replayed, which eliminates duplicate writes caused by network instability.
Error handling: A single typed exception model separates diagnostic data (status code, request ID, cause) from the user-facing message. Response bodies and internal detail are never rendered to the user, and verbose logging is compiled out of release builds.
Authorization: The authoritative subject identity is the verified token's sub claim. Role, organisation and tenant scope are resolved server-side per request; client-supplied context is not treated as authoritative. Endpoint-level permission is enforced independently of the client's navigation state.
File transfer: Uploads and downloads use short-lived, backend-issued signed URLs requested over an authenticated channel. Object data never transits the application server.
Encryption in transit: All backend communication is over HTTPS using TLS 1.3. Earlier TLS versions (1.0, 1.1, 1.2) are disabled at the edge and plaintext HTTP is not served. Authenticated responses are marked non-cacheable so credentials-bearing content is not retained by intermediaries.
Encryption at rest: The platform is hosted on Google Cloud Platform. All customer data at rest is encrypted by default at the storage layer using AES-256, with key management by Google Cloud KMS and automatic key rotation. This applies uniformly across our managed data stores and object storage; no data is written to unencrypted media. Customer-managed encryption keys (CMEK) can be discussed where your policy requires key custody.
Multi-factor authentication: Supported, and can be enabled per tenant on request.
Availability & recovery: The database runs in a high-availability configuration on Google Cloud Platform, with recovery procedures designed to restore service in minutes.

Assurance

What's certified, and by whom.

Vendors who blur this line are the ones worth worrying about, so we draw it ourselves.

Our controls: SIT operates SOC 2-aligned controls, positioned around access management, audit trails, monitoring, secure change management and data protection.
Infrastructure: Google Cloud Platform maintains ISO/IEC 27001, 27017 and 27018, SOC 1/2/3 and PCI DSS certifications covering the infrastructure layer on which the platform runs.
The distinction: Those certifications attest to Google's controls, not to an independent audit of our application. We are explicit about that in every vendor assessment, and we'd rather say it here than be asked.

Discuss security requirements

Performance

The question an architect always asks about interpreted systems.

It is a fair one: if the application is read from a definition rather than compiled, what does that cost at runtime? The short answer is that definitions are resolved once and cached, so you are not paying resolution overhead per request. The longer answer is the one worth having, and we would rather give it than a reassuring adjective.

Request path: Resolved definitions — base, customer layer and role layer combined — are cached in memory. A request reads a prepared structure rather than re-interpreting metadata from scratch.
Bulk and batch: Large imports and scheduled recalculations are the workloads where interpreted execution actually costs something, and where a metadata cache does not help. We will talk about your specific volumes rather than quote a general number.
Definition changes: A change to a definition invalidates the cache across nodes. We will walk your team through the propagation behaviour and what a user sees during it.
Mobile and offline: The mobile client caches both definition and working data. Conflict resolution on reconnect is a design decision we make with you, not a hidden default.
Ask us for the profile: If you are evaluating us on load, ask for the performance profile and we will give you measured figures against a defined reference workload, alongside your own volume assumptions. We would rather be assessed on numbers than on claims.