Privacy policy

1.Whose data this is

Two different relationships run through ChurchOS and conflating them would misstate everybody's rights.

For the records a church puts into ChurchOS about its congregation — names, households, attendance, pastoral notes, connection requests — the church decides what is collected and why. ChurchOS holds and processes that data on the church's instructions and does not decide what to do with it. In data-protection language the church is the controller and ChurchOS is the processor.

For the church's own account with us — the staff accounts that sign in, the church's billing details when billing exists, our records of support conversations and our security logs — ChurchOS decides what is collected and why, and is the controller.

A person in a church directory who wants their record corrected or removed should ask their church, because their church is the only party entitled to decide. If they write to us instead we will tell them so and, where we can identify the church, tell the church that a request was received.

2.What ChurchOS collects

Three categories, and nothing outside them.

• Account data a church gives us directly: church name, chosen address, staff names, email addresses, and a password which is never stored in a readable form.
• Congregation data a church enters or a member submits through the church's own site: people and household records, attendance, guest and connection cards, pastoral notes, service plans, sermon material and worship content.
• Technical data produced by using the software: sign-in and permission events in an audit log, error reports, and ordinary web-server request records.

3.What ChurchOS does not collect

This site carries no third-party analytics, no advertising pixel and no social-media tracking script. There is nothing on these pages that reports your visit to anybody else, so there is no cookie banner to dismiss — there is nothing to consent to.

ChurchOS does not process card payments today. No payment processor is connected to the platform, no card details reach it, and no church can currently be charged through it.

ChurchOS does not sell data, does not share it with advertisers, and does not build a profile of a congregation across churches.

4.Separation between churches

Every table holding church data carries a row-level security policy enforced by the database, not by application code. One church cannot read another church's records even if the software asked it to, and the policies apply to the account that owns the schema as well, so there is no privileged path that quietly bypasses them.

This is verified rather than asserted. The test suite attempts cross-church reads in raw SQL, in both directions, on every change, and a wrong policy fails the build.

5.Pastoral notes

Notes written about a person in confidence are treated differently from the rest of a directory. Each note carries a visibility level chosen by the church, and a note restricted to pastoral staff is not readable by an administrator, by a volunteer, or by anybody at ChurchOS working through the ordinary product.

Reads of the most sensitive records are recorded in the church's audit log, so a church can see who looked as well as who wrote.

6.Cookies

ChurchOS sets cookies for one purpose: keeping somebody signed in. There are two, they are set only after a successful sign-in, and neither is used for tracking.

• `churchos_session` — the session for a person signed in to a church. Scoped to that church's address.
• `churchos_platform_session` — the session for ChurchOS staff signed in to the platform console. Scoped to the console's own hostname and deliberately never sent to any church address.

7.Other companies involved

ChurchOS uses as few outside services as it can, and each one is listed here rather than summarised as "our trusted partners".

• Resend — sends transactional email such as address verification. Receives the recipient address and the contents of that message.
• Sentry — receives application error reports so faults can be diagnosed. Error reports can incidentally contain identifiers such as a user or church id.
• A hosting provider, which operates the servers the platform and its database run on.

8.Artificial intelligence

The study and sermon-preparation features use a language model that ChurchOS runs itself. The only two providers the software can be configured to use are a local model server and a mock used in testing; there is no code path that sends church content to a commercial AI provider.

Church content is not used to train any model, ours or anybody else's. Assisted answers are required to cite the source material they came from or not be given at all.

9.Security

Passwords are hashed with Argon2id and are never stored, logged or recoverable — a lost password is reset, not retrieved. A failed sign-in returns one message regardless of which part was wrong, so the form cannot be used to work out who has an account.

Stream keys, broadcast passwords and provider tokens are encrypted at rest and cannot be displayed again after they are entered. Traffic is served over TLS with HSTS.

ChurchOS 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.

10.How long data is kept

While a church uses ChurchOS, its data is kept until the church deletes it.

What happens after a church leaves has not been settled. There is a working assumption inside the engineering team of a thirty-day window before deletion, but no owner has approved it, no scheduled deletion has been built, and nothing in this platform currently enforces any retention period. Stating a number here that nothing implements would be worse than admitting the gap, so this section will be completed before this document takes effect.

11.Getting your data out

A church's records belong to the church, and our position is that a church must be able to leave with them.

The mechanism does not exist yet. There is no self-service export in the product today and no automated deletion request. Until there is, a church that wants a copy of its data or wants it deleted should write to us and we will do it by hand.

12.Children's records

ChurchOS has no children's ministry module. There are no records for a child, a guardian or an authorised pickup, and no check-in workflow designed around child safety.

A church should not use the general people directory as a children's register, and must not rely on ChurchOS for any child-safeguarding process. If a church has entered records about children into the directory anyway, those records are treated as ordinary congregation data under this policy, which is very likely not the standard that church's safeguarding policy requires.

13.Changes to this policy

When this document takes effect it will carry an effective date and a version, and both will change when the document does. Churches will be told about a change that materially affects them before it applies, through the address they signed up with.

14.Open items this draft cannot answer

Listed rather than guessed. Each one needs a decision from the owner of ChurchOS or advice from a lawyer before this policy can bind anybody.

• Which legal entity publishes ChurchOS, its registered address, and the law and courts that govern this policy.
• The country the servers and database backups are held in, and whether any church data crosses a border.
• Which data-protection regimes ChurchOS holds itself to, and whether a representative is required in any of them.
• The retention period after a church leaves, and the deletion mechanism that enforces it.
• Whether a written processor agreement is offered to churches, and on what terms.
• Where to send a complaint if a church is unhappy with an answer from hello@mychurchos.app.