About This Document
This document explains how the Church Management Platform protects your church's data. It is written for church leadership and decision-makers—no technical background required. If your church has technical staff who want deeper implementation details, they can find those in the Technical Addendum.
Our Commitment
Churches entrust us with their most sensitive information: the names, contact details, and financial records of their members. We take that trust seriously. The platform is built from the ground up so that:
- Your data lives on your own dedicated server—not shared with anyone.
- The platform developer cannot view your member records or financial data, even with server access.
- Your church holds the master credentials—you control who has access.
- These boundaries are enforced by the database itself, not just software settings that could be changed.
How Isolation Works
Each church deployment is fully independent. There is no shared database, no shared server, and no central system where multiple churches' data is combined.
Dedicated Server
Your church runs on its own private server (a Virtual Private Server or a host you provide). No other church or organization shares your hardware.
Dedicated Database
Your member data, giving records, attendance history, and all other information lives in your own PostgreSQL database instance. It is not co-mingled with any other church's data.
Dedicated Domain
Your church accesses the platform through its own web address (e.g., manage.yourchurch.org), secured with its own SSL certificate for encrypted connections.
Visual Overview
Own server
Own database
Own domain
No data sharing
Own server
Own database
Own domain
Each church is a completely separate installation. There is no shared infrastructure.
People & Member Data
The following types of information are stored exclusively in your church's private database and are inaccessible to the platform developer:
- Personal information — names, dates of birth, addresses, photos
- Contact details — phone numbers, email addresses
- Family relationships — who belongs to which family, family roles
- Group memberships — ministry groups, small groups, departments
- Attendance history — check-in records, event attendance, small group attendance
- Account credentials — user accounts, passwords (stored as irreversible hashes), login history
- Event registrations — who signed up for what, form submissions
- Service planning — volunteer schedules, team assignments, availability
Financial & Giving Data
Financial data receives the same level of isolation as member records:
- Individual donations — amounts, dates, payment methods, fund designations
- Donor history — per-person giving totals, year-end summaries
- Recurring gifts — scheduled donations, subscription details
- Fund management — giving funds, categories, allocations
- Giving reports — trends, summaries, fund breakdowns
Payment processing (PayPal) connects directly to your church's own PayPal account. Donations flow from the donor to your church—the platform developer never handles or sees the funds.
Who Has Access to What
Access is divided into two completely separate tiers. This separation is enforced at the database level—it cannot be bypassed by changing application settings.
| Capability | Church Administrator | Platform Developer |
|---|---|---|
| View member records | Yes | No |
| View giving/donation data | Yes | No |
| View contact information | Yes | No |
| View attendance records | Yes | No |
| Manage user accounts & roles | Yes | No |
| Log into the web application | Yes | No — no account exists |
| Toggle feature modules on/off | Yes | Yes — via server command only |
| Deploy software updates | No (unless granted server access) | Yes |
| Run database schema updates | No (unless granted server access) | Yes — structure only, not data |
Credential Ownership
During setup, all sensitive credentials are handed to the church administrator. The platform developer does not retain copies of credentials that grant data access.
Church Holds
Database master password, application database password, Church Administrator web login, and the ability to grant access to their own technical staff.
Developer Holds
Server login (SSH) for deployments, and a restricted database password that can only access configuration tables (feature toggles, module settings). No access to data.
What the Platform Developer Can Do
The platform developer retains just enough access to keep the system running:
- Deploy software updates — push new features and bug fixes to the server
- Run database structure changes — add new tables or columns when features are added (does not touch existing data)
- Toggle feature modules — enable or disable optional modules via a server-side command
- Monitor system health — check that the application is running, server resources are adequate, and SSL certificates are valid
- View application logs — for debugging errors (logs do not contain personal data)
What the Platform Developer Cannot Do
These restrictions are enforced by the database, not just application code:
- Cannot view, search, or export member names, contact info, or personal details
- Cannot view donation amounts, giving history, or donor information
- Cannot view attendance records or check-in history
- Cannot view family relationships or group memberships
- Cannot log into the web application (no account exists for them)
- Cannot create user accounts or reset member passwords
- Cannot impersonate any user or assume any role in the application
- Cannot access your church's PayPal account or see payment details
Church Administrator Role
Your designated Church Administrator is the highest-level user in the application. This person can:
- Manage all user accounts and assign roles
- Grant or revoke individual permissions for any user
- Access all modules: people, families, events, groups, giving, reports, and more
- Enable or disable feature modules through the web interface
- Configure integrations (Planning Center, PayPal, email)
There is no role above the Church Administrator within the application.
Technical Staff Access
If your church has technical staff (IT volunteers, a tech-savvy elder, etc.), the Church Administrator can grant them:
- Direct database access — connect to PostgreSQL with a database client for custom queries, reports, or data exports
- Server access — SSH login to the server for maintenance, backup verification, or log review
- Code review — read access to the source code repository to audit what is deployed on their server
These are entirely at the church's discretion. The platform developer will assist with initial setup but does not control who your church grants access to.
Backups & Data Export
Automated database backups run on your server and can be configured to send copies to a location your church controls (e.g., your own cloud storage). The platform developer does not receive or retain backup copies of your data.
Your Church Administrator can export data at any time using the built-in report and export features, or your technical staff can run direct database queries for custom exports.
Setup Process
When onboarding a new church, the process works as follows:
- Server provisioning — the platform developer sets up a new server with all required software (operating system, database, web server, application code).
- Credential handoff — all sensitive passwords are generated and handed to the Church Administrator. The developer's own credentials are restricted to configuration-only access.
- Data import — existing member data from a previous system is imported. This can be done by the church's technical staff, or by the developer with a temporary password the church provides (and changes afterward).
- Validation — the church tests all features on the new domain while their existing system remains active.
- Go live — only after the church is satisfied, they update their domain's DNS to point to the new server. The old system is decommissioned at the church's pace.
Transition & DNS Cutover
The transition is designed to be zero-risk:
- Your existing system stays fully active on its current domain throughout the entire testing period
- The new platform runs on a separate domain for testing (e.g., new.yourchurch.org)
- Your church controls when (and if) the DNS switch happens
- If anything is unsatisfactory, the old system is still right where you left it
Audit & Transparency
For churches that want additional assurance:
- Database connection logging — PostgreSQL logs every connection attempt, including which credential was used. Your technical staff can review these logs to verify that the developer's restricted credentials are never used to access data tables.
- Update notifications — the platform developer notifies your church before deploying any code changes. Your technical staff can review the changes before they go live.
- No remote database access — by default, the database only accepts connections from the server itself (localhost). Remote database access is disabled unless your church explicitly enables it for their own staff.
Code Review Access
The platform's source code is available for review by your church's technical staff. This means your team can verify that the privacy boundaries described in this document are actually implemented in the code—not just promised in a document.
The codebase is standard, unobfuscated .NET (C#) and React (TypeScript)—widely known technologies that any competent developer can read and understand.