The records a ministry keeps about its people are among the most sensitive it holds. This page explains how we treat them in plain language — what runs today, and what we're building next, clearly marked.
Not policies. Not intentions. Behaviors of the running system — and the rest of this page stands on them.
Every data request is scoped to the caller's organization by an isolation layer the platform itself enforces — not something each feature has to remember to do. If the system cannot establish who you are and which organization you belong to, it returns nothing. The default is closed.
Every protected action is checked against fine-grained, permission-level authorization on the server — not just hidden in the interface. What a role cannot see in the app, it cannot reach by calling the API directly, either.
Data is encrypted in transit and at rest. The most sensitive fields are gaining an additional envelope-encryption layer whose master keys live only in a managed key vault — so a stolen copy of the database stays unreadable without separate access to the vault.
Automated security tests run against our deployed environments: probes that attempt cross-tenant access, and real-browser tests that walk each role through the product. Isolation and access rules are re-proven, not assumed from a design document.
Payroll funds get a purpose-built, isolated home — separate infrastructure, separate network, separate data store — built security-first from its very first commit. Here is the path every payment takes, and the rules that path enforces.
Every deposit is screened against the client's own payment history before anything moves. The question is always the same: is this normal for you?
A changed bank account is always held for human review. That check has no off switch — by design, not by configuration.
Every individual money decision requires a fresh tap of a physical hardware security key. One tap authorizes exactly one decision — never a batch, never a session.
A payment file that doesn't balance against its own control totals is never produced. Not flagged afterward — never written in the first place.
When a person approves an exception, the system learns that employee's new normal — it never generalizes the exception into a weaker rule. Standards don't drift downward because someone once said yes.
The screening rules are deliberate, human-readable decisions — an auditor can read exactly why a payment was held, not shrug at an opaque model. They were calibrated against two years of real payroll history.
A church's records belong to the church. On this page that's not a slogan — it's a set of specific commitments. The numbered marks point to the fine print at the bottom of the page, which says exactly where each one stands.
We build for congregations, and congregations are communities — the person in the database is also the person in the pew. That shapes how long we keep things, who can see them, and how completely they can be removed.
Each church's data lives in its own isolated environment — never a shared database.
We deliberately keep no long-term backups of identifiable data — nothing sits in an archive that a deletion couldn't reach.
Sign-in sessions are short, so disabling a user takes effect within hours — not whenever they next log out.
It records who did what, and when — deliberately designed never to capture personal data itself.
Most of security is unglamorous. These run on every request, every day — no footnotes in this section.
Every sensitive action is recorded in an audit trail, with a correlation ID that ties activity together across the platform. When your admin asks what happened, we can answer precisely.
Payment processing is handled by a PCI-certified provider. We store no card numbers — there is nothing on our systems to steal.
Request rate limits keep any single caller — accidental or hostile — from crowding everyone else out of the platform.
All input is validated at the boundary, and every database access is parameterized. Old discipline, applied everywhere.
No badges we haven't earned. The current state, in the same plain language as the rest of this page.
Across all databases — every one, not a subset.
Preparation is underway — the same status we publish on our roadmap.
Data is retained to meet financial-record and tax obligations, and deletion workflows respect legal retention.
Correction and deletion are supported for the people in your records.
The fine print — because a board should never have to guess:
Encryption rollout. Everything is encrypted in transit and at rest today. The envelope-encryption layer is the additional lock on top — live in production and being extended field by field across the platform's most sensitive data.
Payment environment — staged rollout. This system earns its responsibility in stages: it proved its screening and controls in a parallel run against real payroll workloads before any funds moved through it, and clients come aboard deliberately, not all at once. Ask where the rollout stands — we'll answer precisely.
Church-data platform. The three commitments marked above — one environment per church, cryptographic deletion with an attestation record, no long-term identifiable backups — are engineering commitments of the platform's design. They hold from the first day it carries a church's live data, and every day after.
We answer security questionnaires and board-level questions in writing, regularly. Bring the hard ones — if something on this page raises a question, that's exactly the conversation we want to have.
