An auditor you can hand your data to.

Posture at a glance

Stated from the code, not a logo

SOC 2, as of 26 July 2026: 20 of 34 controls met and code-enforced, with 9 partial and 5 deferred. The full control-by-control readiness report is available on request.

The readiness report — the full control-by-control matrix, including the 9 partial and 5 deferred controls — is available on request for a security review. We would rather show you the gaps than paper over them.

A DPA is available on request — email security@spendassay.com.

The bright lines

Hard limits, enforced below the UI

These are architectural constraints, not settings a customer or a salesperson can turn off. They survive a works-council review and a security questionnaire because they are enforced in the data layer.

• The audit is read-only — it never writes to your systems

  Spendassay connects through read-scoped access to billing, vendor usage data, and Git/CI. It cannot merge a PR, revoke a seat, change a license, or write to any system you connect. Recoveries run as guided step-by-step instructions your own admins execute — approved, tracked, and audited in-product, with zero vendor API writes. Routing and throttling are Control, a separate opt-in plan (private beta) that runs on your own provider keys. It is never enabled by default, and it never touches the audit's connectors.

• Metadata only — never your code or content

  The audit reads counts, timestamps, churn, and review events — the statistics measurement actually needs. It does not read, store, or transmit source code, diffs, file contents, prompts, or message bodies. Identity connectors read sign-in metadata only: who signed in to which app, when — never email or file content.

• Team-level only, minimum cohort of eight

  No productivity figure renders for a group smaller than eight people — a hard floor enforced below the UI, not a setting. There are no per-person rankings and no surveillance leaderboards. Below the floor we suppress the number rather than risk re-identifying an individual from an aggregate.

• Tenant isolation enforced by the database

  Every request is served by a non-owner database role, so the database itself keeps each customer's data apart: a policy filters every table to the caller's organization, and one tenant's query cannot reach another tenant's rows even if application code forgot a filter. Isolation is a database guarantee, not a convention in the app layer.

The request path

The optional gateway, and what it does not do

Everything above describes the audit, which connects read-only to systems you already run. The request-path proxy is a different product with a different posture, so it gets its own bright lines rather than sheltering under the audit's. It is open source, so you can read every line of it before you run it. This is the posture behind Spendassay Meter, which is observe-only and never routes or throttles at all.

• Separate, and opt-in

  The audit needs no gateway. The proxy is a distinct component you run yourself — it only ever sees the traffic you deliberately point at it, and running it changes nothing about the audit's read-only posture.

• Nothing is stored

  The proxy reads token counts, model, latency, and your tags off each request. It never stores your prompts or completions. Request and response bodies pass through and are discarded; only the usage numbers and tags are sent to Spendassay.

• Verbatim unless you say otherwise

  The gateway forwards your request verbatim unless you configure a routing rule. With routing configured it changes exactly one field — the model — and re-serializes every other key untouched.

• You declare what's routine

  Routing fires only on tags you set, never on an inspection of your prompt. There is no classifier reading your content to guess difficulty, which means no added latency, no extra inference hop, and a routing decision you can audit line by line.

• It fails open

  A malformed rule, an unparseable body, or a Spendassay outage all degrade to forwarding your original request. The proxy is designed so that its own failure cannot become your outage.

How your data is protected

The controls behind the claims

Assurance

What we have not done yet, said plainly

Data lifecycle

What we hold, and how it leaves

What each connector reads

Scoped to the metadata the audit needs

Every connector is read-only and scoped to the smallest signal that answers the question. Below is the literal permission string each one requests, so you can pre-clear the grant before you authorize it rather than take an adjective on trust. These are read from the connector code and a test fails the build if this table drifts from what we actually ask for.

Sub-processors

The short list of services we rely on

These process customer data. They are the list in §6 of the privacy policy, and we give at least 30 days' notice before adding one.

Website analytics

On the marketing site only, never on your data

These run on public marketing pages, never inside the application and never against connected data, so they are not sub-processors under §6. They are disclosed in the privacy policy too. Apollo.io does not honour Do Not Track; PostHog does.

Responsible disclosure

Found something? Tell us.

If you believe you've found a security issue, email security@spendassay.com with the details and steps to reproduce. We'll acknowledge, work the fix, and keep you posted — and we won't pursue good-faith researchers who follow this process.