Security & continuity

Last updated 23 August 2026

Churches have been burned by platforms that went quiet. This page is what we would want to read before trusting someone with a congregation's records — including the parts that are not flattering.

Where your data lives

Google Cloud, us-central1. The database has no public IP address and is reachable only from our own application over a private network. Files and photos sit in Google Cloud Storage.

Encryption

Everything in transit is TLS, with HSTS and preload set.
Everything at rest is encrypted by Google Cloud.
Passwords are hashed with bcrypt. We cannot read them, and neither can anyone who takes the database.

Card data

Card numbers never reach our servers. Payment fields are hosted by Stripe and submitted straight to them. Gifts are charged on the church’s own Stripe account, so the money never enters a 1Prov balance either.

Access

Every screen is scoped to one church; a signed-in person cannot reach another congregation’s records by changing a URL.
Roles run from Member to Admin, and giving is visible only to the roles a church chooses.
Significant admin actions are written to an audit log the church can see.
Platform-level actions — deleting a church, changing a plan — are recorded in a separate log that survives the record it describes.

We can open a church’s admin for support. That is deliberate, it is logged, and the console says plainly that we should tell the church when we do it.

Backups and recovery

Automated database backups every day, retained 14 days.
Point-in-time recovery is enabled, so we can restore to a moment rather than only to last night.
Backups are encrypted and stored by Google Cloud, separate from the running database.

We have actually tested this. On 24 August 2026 we restored production to a separate database at a chosen point in time, connected to it, and confirmed the schema and every migration came back intact. The restore took 35 minutes end to end, and the rehearsal instance was destroyed afterwards.

So our recovery time objective is under an hour for a full database restore, and our recovery point objective is minutes, because point-in-time recovery replays the transaction log rather than jumping to last night’s snapshot. We will re-run this rehearsal each quarter and update the date above.

Application security

Church-authored content is sanitised before it renders, so a page cannot carry a script.
A Content-Security-Policy restricts what a page may do even if something got through.
Session cookies are httpOnly and SameSite, so they cannot be read by scripts.
Sign-in supports Google Workspace, and a church can require it for its own domain.

Getting your data out

Any administrator can export their church’s data from the admin at any time — people, giving history, pages, sermons and events — without asking us and without a support ticket. Your domain is registered to you, not to us, so leaving means changing one DNS record.

We would rather earn next month than make leaving difficult.

Reporting a problem

If you find a vulnerability, email support@holdfast.church before disclosing it publicly. We will confirm within two business days and tell you honestly what we find. We will not threaten anyone who reports something in good faith.