Security & trust
Churches hold information that is not ordinary customer data
A note a pastor wrote in confidence, a family's address and phone number, who asked for prayer on Sunday, who was in the building. 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.
Leaving is a commitment, not yet a button
A church's records belong to the church, and we will not hold a congregation hostage. Self-service export is not built yet, so today a church that wants a copy of its data, or wants it deleted, asks us and we do it by hand. We would rather describe the manual process that works than an automated one that does not exist.
What we do not have
ChurchOS is pre-launch and has not completed an external penetration test or a SOC 2 examination. We would rather say so than imply a certificate we do not hold.
There are also two categories of church record ChurchOS does not hold at all, because the modules are not built: giving — no donation, fund or gift is recorded anywhere in the platform — and children's records, which means no child, guardian or authorised-pickup register exists. A church running children's ministry should keep whatever it uses for that; the acceptable use policy says the same thing and means it.
The database is backed up on a schedule with integrity checks and rehearsed restores, but those backups are currently held on the same machine as the database. That covers a bad deployment or a mistaken deletion; it does not cover losing the machine. Off-site backup is required before ChurchOS is sold commercially and is not in place today.
The privacy policy sets out what is collected and who else processes it, and the acceptable use policy covers reporting a vulnerability. Both are drafts pending legal review.