Built to pass the board's review.
Churches hold sensitive data: giving records, pastoral notes, children's information. SanctuaryIQ treats protecting it as the platform's first job, starting with a decision most vendors can't make: there is no third-party code in the codebase.
Zero third-party frameworks. Zero dependency exposure.
Most modern software is assembled from hundreds of open-source packages the vendor has never read, and every one of them is a potential way in. SanctuaryIQ was written from scratch, in-house, with no external libraries or frameworks in the application core. There is no dependency chain to inherit vulnerabilities from, no supply-chain attack surface, and no waiting on an upstream patch when a framework CVE makes the news. Every line in production is a line we wrote, read, and can defend to your reviewer.
Defense in depth, in the code itself.
Multi-tenant isolation
Every church is fully isolated. Tenant scoping is enforced at the query layer, not as an application convention. No shared state, ever.
Role-based access control
Built-in roles: Member, Volunteer, Group Leader, Staff, Pastor, Finance, Admin, Executive. Confidential pastoral notes are visible only to authorized roles.
PCI-aware payments
Online giving runs on a PCI-DSS compliant processor. The platform never touches a card number: tokenized at the form, charged via the gateway.
Encrypted credentials
Per-organization API keys for payments and integrations are encrypted at rest, with server-level configuration as the fallback when no tenant key is set.
Encryption in transit
HTTPS-only across every surface, modern TLS with no legacy protocols, and signed, verified public webhooks.
Audit trail
Every mutation is logged with user, timestamp, and source: gifts recorded, people edited, pastoral notes added, roles changed. Full replay per record.
Pastoral notes that stay pastoral.
Priests and senior pastors ask this first, because the platform's first users did. Pastoral notes, prayer requests, and care details are role-gated, access-logged, and excluded from generic AI prompts unless explicitly authorized.
Confidential by default
- Pastoral notes are visible only to authorized care roles, never to general staff
- Prayer requests can be marked private or anonymous at submission
- Sensitive life events such as illness or family crisis are flagged and access-logged
Giving is treated separately
- Individual gift amounts are restricted to finance roles and the senior pastor
- Executive roles see aggregate giving health without individual records
- Donor information stays out of AI prompts unless a finance task requires it
Member-facing controls
- Members view and update their own profile, family, and communication preferences
- Each member sees only their own giving history and statements
- Data export and right-to-be-forgotten workflows where jurisdictions require them
What is logged
- Every read of a pastoral note: who, when, from where
- Every export of a giving list, with a reason annotation
- Every role grant or revocation, in an immutable audit log
How the AI features use your data.
Boards ask this second. AI calls are scoped to your church, rate-limited, read-only for analytics, and never used to train a third party.
Scoped & isolated
- Every AI call is scoped to the calling user's church, with no cross-tenant exposure
- The Pastoral Assistant is read-only: it analyzes data, it does not modify it
- Your own model API keys are honored when configured
Rate-limited & tracked
- Per-user rate limits prevent runaway cost or abuse
- Every AI call is logged with user, model, token usage, and outcome
- Cost-optimized models on high-volume paths, flagship models for drafting and analysis
What is sent to the model
- Only the context required for the task, never your whole database
- Pastoral notes and confidential prayer requests are excluded from generic prompts
- Donor personal information is excluded from drafting prompts unless personalization is explicitly requested
What is not
- Your data is not used to train third-party models
- Church data is never shared across organizations, not for AI and not for benchmarking
- AI features can be disabled entirely for your church if your board requires it
What boards and administrators need for the review.
Documentation for review
- Security questionnaire responses (SIG-lite, CAIQ format)
- Data Processing Addendum (DPA) on request
- Standard MSA and SaaS subscription terms
- Reference architecture and data-flow diagrams
- Insurance certificates on request
Deployment & onboarding
- Cloud-hosted SaaS with no servers to provision
- Per-tenant subdomain or your own custom domain
- Standard onboarding of campuses, ministries, and people imports in 2–4 weeks
- Start with one ministry and expand when ready
- CSV import for existing people, giving history, and pledge data
Church-friendly licensing
- Per-church pricing with every module included
- Annual or monthly billing
- Discounted tiers for church plants and small congregations
- No-cost pilot programs for qualifying churches
Support & SLA
- A direct line to the engineers who wrote the code, with no tier-1 maze
- Standard 99.9% uptime target
- Status page for incidents and planned maintenance
- Documented backup and restore procedures
Familiar frameworks for IT review.
Controls are aligned to recognized security frameworks and payment-industry standards, and formal certifications are added as the customer base requires them.
Need our review packet?
Send us your board's questions and we'll respond with the security questionnaire, DPA, and reference architecture. Answers come from the engineering team, because that's who we are.
Request the packet arrow_forward