ChurchCore holds sensitive ministry information: pastoral care notes, giving records and children's check-in. This page says plainly what we do to protect it, and what we have not finished yet.
Each statement below describes how the product works today.
The database enforces isolation for every table that holds a church's records, and the application backs that up: server code checks who is signed in and which church they belong to, and every page is tested with every role. A mistake in a database rule or in server code is the main risk, which is why we test for it.
ChurchCore's own administration runs in a separate project from your church's data. Only people on an explicit list of platform staff can reach a church's account, and when staff view an account as its user would see it, that session is recorded.
Donations and event payments are paid directly into your church's own Stripe account, so ChurchCore never holds your church's money. Card details are typed into Stripe's secure form and do not reach our servers.
These are encrypted before they are saved: pastoral care notes, care-assignment summaries, elder council documents, and two fields on children's records (special-needs notes and custody notes). The key is held by the application, not the database. Not every sensitive field is covered yet; see "Still being built" below.
AI requests are made from our servers, never from your browser. Before text is sent, we replace email addresses, phone numbers and ID numbers with placeholders; names and other wording are not removed. Requests go through OpenRouter, and we require providers that keep no copy of the request. If none is available, the request fails instead of going elsewhere. ChurchCore can also call Anthropic directly as a backup route, and that route does not use OpenRouter's zero-retention setting.
Each check-in gets its own random pickup PIN, stored only as a bcrypt hash, the way passwords are stored, so it cannot be read back. Check-in kiosk pages are marked do-not-store, so a roster of children is not kept in the tablet's cache.
Rules we hold ourselves to, and the check behind each one.
| Area | Rule | How it is checked |
|---|---|---|
| Church data separation | Row-level security is switched on for every table that holds church data. | An automated check runs on every code change and blocks the release if a table is missing it. It confirms protection is on and a rule exists; tests for every page and role cover what the rules allow. |
| Staff and church data | Platform administration lives in its own project, apart from church data. | A separate project with its own staff sign-in. |
| Privileged database functions | They identify the user from the signed-in session, never from a value the caller supplies. | A written engineering rule, with database tests for sensitive functions. |
| Messages from other services | Messages from Stripe, Resend, SendGrid and Twilio are accepted only with a valid signature. | Each provider's own signature method is verified; unsigned messages are refused. |
| Scheduled jobs | They need a secret key, and refuse to run without one in production. | The key is checked on every run; a missing key means the job does not start. |
| Erasure requests | A member asks, a church administrator approves, and erasure is limited to that person and their household. Audit history is redacted rather than deleted. | Covered by database and browser tests. |
| Browser protections | Our pages cannot be shown inside other websites, and browsers are told not to guess file types. | Sent as security headers on every response, and covered by a test. |
Things we have not finished, so you are not left to assume.
Prayer requests, elder notes and council notes are protected by the database's access rules but are not encrypted separately. Encrypting them is planned.
Our browser content-security policy is in monitoring mode: it reports problems but does not block anything yet. We will switch it on once we have confirmed it does not break payments or pages.
If you find a possible vulnerability or a data protection problem in ChurchCore, please email security@churchcore.io instead of posting it publicly. We review each report, fix confirmed problems and release the fix.