Security & trust
Churches hold information that is not ordinary customer data
Who is in crisis, who gives what, which children belong to whom. The protections below are architectural rather than procedural — they do not depend on anybody remembering.
Separation is enforced by the database
Every table holding church data carries a row-level security policy. One church cannot read another's records even if application code asked it to — and the policies apply to the schema owner too, so nothing bypasses them quietly.
Proven in both directions, continuously
Isolation is not a claim in a document. A test suite attempts cross-church reads in raw SQL, in both directions, on every change. If a policy were wrong, the build would fail.
Pastoral notes are not staff-wide
A note written in confidence is readable by the people a church chose and by nobody else, administrators included. Reads of sensitive records are recorded.
Credentials are shown once
Stream keys, OBS passwords and provider tokens are encrypted at rest with envelope encryption. No screen in the product can display one afterwards, and none appears in a log or an audit entry.
Passwords are hashed with Argon2id
Never stored, never logged, never recoverable. A failed sign-in gives one message regardless of which part was wrong, so the form cannot be used to discover who has an account.
Your data leaves with you
Every module exports. A church that cancels takes its people, giving history and sermon archive with it. Software that holds a congregation hostage is not something we are willing to build.
ChurchOS is pre-launch and has not yet completed an external audit or a SOC 2 examination. We would rather say so than imply a certificate we do not hold.