Skip to main content

Security & trust

Sensitive church work deserves clear boundaries.

A church platform holds prayer requests, family details, kids' check-ins, and pastoral notes. This page describes how FaithIt protects that work today — plainly, and only where the product actually backs it up.

This is a practical product overview — not a certification, compliance attestation, contractual security schedule, or uptime commitment.

How access worksIdentity → active church → path-specific check → action

Depending on the operation, FaithIt uses role checks, church assignments or memberships, collection-specific rules, and server-mediated workflows.

Current controls

Described at their actual boundary.

These statements intentionally avoid universal tenant-isolation, certification, transport-policy, or reliability claims that the product does not establish.

01

Staff console entry checks

The web console requires an authenticated account, a staff role, and a non-default active church context before opening staff workspaces. This describes console entry; individual data paths still apply their own rules.

02

Collection-specific authorization

Roles and explicit permissions are used by staff navigation and many protected operations. The exact check depends on the route, collection, and server workflow; this page does not claim one universal authorization rule.

03

Church scope and legacy boundaries

Many protected church-scoped collections compare a requested church with an authenticated assignment or membership record. The current rules also retain legacy/default behavior and collection-specific exceptions that require path-level review before reliance.

04

Moderation and visibility gates

Prayer requests, testimonies, join requests, and other submitted content can use approval and visibility rules where those workflows are configured. Visibility still depends on the exact collection and request path.

05

Selected server-managed family fields

Selected minor, household, consent, and audit fields are protected from ordinary client edits. Eligible family and child actions use server-mediated checks in the represented workflows.

06

One-time check-in codes

Child check-in creates a pickup code that is returned once to the authorized workflow. Only a hash is persisted, and checkout validates the presented code without exposing the stored hash in member-facing responses.

07

Client HTTPS redirect

The web client redirects detected production HTTP sessions to the corresponding HTTPS URL. This is a client behavior and is not presented as evidence of edge-level TLS policy or HSTS enforcement.

08

Purpose-specific machine access

Production agents use a separate church-scoped identity path with an active-agent record instead of inheriting general staff access.

What this overview means

Specific about controls. Careful about claims.

This page is

A readable summary of selected controls and known boundaries in the current FaithIt product.

  • A starting point for your church's trust questions
  • A map of selected access and workflow boundaries
  • A commitment to distinguish current behavior from roadmap work

This page is not

A substitute for a church-specific review, legal assessment, or independent audit.

  • No certification or compliance status is asserted
  • No uptime, recovery, or response-time promise is made
  • No payment-processing assurance is described here
  • No universal control is inferred from a narrower implementation

As you set up your church

A short checklist worth walking through.

When you enable modules and invite your team, take a few minutes to match access to responsibility. A demo covers all of this too.

  • Confirm staff roles and any custom permissions
  • Confirm who reviews prayer, testimony, and join requests
  • Confirm which member modules are enabled
  • Walk through household, child, and check-in responsibilities
  • Review production-agent access if that capability is configured
  • Write down any open question and send it to us

Ask directly

Bring the security question your church needs answered.

We'll answer against how the product actually works today, and tell you plainly where configuration or further review would still be needed.

Email a security questionThis overview does not replace a church-specific review.