Trust

The posture we publish before you ask

Most vendors in the church accounting space lean on AWS-inherited posture. We commit, on day one, to SOC 2 Type II, a published SLA, per-entity database isolation, and a verifiable ledger. Here is the detail.

Request a security review →Security details

At a glance

What we commit to, in writing

SOC 2 Type II

Path committed in ADR-0008; Type I within 6 months of GA

99.9% SLA

Published service credits — see /trust/sla

Per-entity database isolation

Database-per-accounting-entity, multi-cluster fleet

Tamper-evident ledger

Hash-chained journal entries; KMS-signed period anchors in WORM

PCI SAQ A

We never store, transmit, or process card data

MFA · SSO · SCIM

SAML/OIDC and SCIM 2.0 on the Firm plan

Quick links

The documents and pages you need

Service Level Agreement →

99.9% monthly availability with proportional credits. RPO ≤ 15 min, RTO ≤ 4 h.

Sub-processors →

Hetzner, AWS KMS (Frankfurt), Stripe, Vanta, Sentry, plus the email + status providers we use.

Security overview →

Encryption, MFA, SSO, RBAC, audit log, file scanning. Our SOC 2 path and PCI SAQ A scope.

Privacy notice →

What data we hold, what we don't, and how to request deletion.

Customer + DPA terms governing your subscription.

Vulnerability disclosure (security.txt) →

security@steepl.co · PGP key on file · Acknowledgments page

What makes us different

Per-entity database isolation + a verifiable ledger

Per-entity database isolation

Every accounting entity gets its own Postgres database, named opaquely (tenant_<ulid>), with a dedicated least-privileged role and per-tenant credentials. Tenants live across a multi-cluster fleet of cluster-pods capped at ~500 tenants per cluster. The control plane is the only routing authority; there is no DNS-based tenant routing.

The practical effect: a missing WHERE tenant_id = ? in our code cannot leak cross-tenant data — there is no other tenant in the database. Restores are per-tenant. Hot tenants can be relocated to their own cluster without touching any other customer.

Tamper-evident ledger

Every posted journal entry stores a 32-byte SHA-256 hash chained from the previous entry's hash. At period close, we compute the Merkle root over the period's entry hashes, sign it with an HSM-backed key in AWS KMS (Frankfurt, FIPS 140-3 Level 3), and anchor the signed root in WORM-locked object storage. We ship a stand-alone verifier CLI that an auditor can run independently to re-derive the chain and verify the period anchor — no DBA can rewrite history without the verifier catching it.

Compliance path, not just claims

SOC 2 Type I targeted within 6 months of GA; Type II within 12 months. Evidence collection runs from day one via Vanta. We hold to PCI SAQ A — card data never traverses our infrastructure. MFA-by-default for all users; SAML/OIDC + SCIM 2.0 on the Firm plan.

What we don't claim

We do not file payroll taxes. Payroll is data + workflow; filing happens through a partner.
We do not file 1099s for you. We produce the data and the IRS-format files; you (or your partner) file.
We are not a card processor. All giving and AP card flows tokenize through Stripe.
We are not HIPAA-covered today. Track this if benevolence/counseling notes become material to you.