Security & trust.

Holy runs on Amazon Web Services in the United States. The application runs on AWS App Runner behind Amazon CloudFront; the database, authentication and file storage are managed PostgreSQL and storage services on Supabase (hosted on AWS in the United States). We do not currently offer regional (EU) hosting.

• ·All traffic is encrypted in transit with TLS 1.2 or higher; HTTP requests are redirected to HTTPS and HSTS is set.
• ·Data is encrypted at rest by the storage provider (AES-256). Backups of uploaded files are written to a versioned S3 bucket encrypted with an AWS KMS customer-managed key (CMK) held in our own AWS account.
• ·Pastoral notes are additionally encrypted at the application layer (AES-256-GCM) before they are written to the database.
• ·Production credentials are held in AWS Secrets Manager and injected at runtime; the platform services authenticate to AWS with IAM roles, not long-lived keys.

Every church is a separate tenant. Every database query the application makes is scoped to the requesting church, the church context comes from the authenticated session and never from client-supplied identifiers, and per-church file storage is path-scoped and signed. Cross-tenant access attempts are part of our automated multi-tenant test suite.

Churches that belong to a diocese or network are grouped under an organisation with explicit, audited cross-church permissions; there is no implicit visibility between churches.

• ·Multi-factor authentication with authenticator apps (TOTP) and passkeys (WebAuthn); backup codes; administrators can require MFA for their whole church.
• ·Enterprise single sign-on via SAML 2.0 with DNS-verified domains, just-in-time provisioning and an optional “SSO required” policy per church.
• ·Passwords are checked against known-breach corpora on set/change; sign-in is rate-limited and locked after repeated failures; new-device sign-ins trigger a notification.
• ·Refresh-token rotation with reuse detection, a per-user concurrent-session cap, and self-service session review and revocation.
• ·Role-based access control with 64 fine-grained permissions across four system roles plus custom roles; every authenticated API endpoint is permission-gated server-side, and premium features are gated on the server as well as in the UI.
• ·Personal access tokens and API keys are scoped to the creator’s permissions, stored hashed, and revocable.

Every create, update and delete is written to an append-only audit log with the acting user, the church, the request identifier and (for registered entity types) the before and after values. Church administrators can filter and export their own audit log from Settings; organisation administrators see the log across their churches. Audit records are retained for seven years.

Card and bank details are entered directly into Stripe’s hosted payment element and never touch Holy servers, keeping our PCI DSS scope to SAQ A. Online giving settles into each church’s own Stripe account (Stripe Connect); Holy never holds donated funds. Webhooks from Stripe are signature-verified and processed idempotently.

• ·Live platform status is published at app.non-prod.holyplatform.com/status.
• ·Databases are backed up by the managed provider; uploaded files are additionally mirrored daily to an encrypted, versioned S3 bucket that keeps prior versions for 90 days.
• ·Every deployment passes an automated test gate (unit, contract and accessibility tests) and a post-deploy health check with automatic rollback.
• ·Errors and latency are monitored continuously with alarms on error rate and p95 latency.

We do not yet publish a contractual uptime SLA. Our recovery objectives and disaster-recovery runbook are available to customers on request; we have not yet run a formal restore drill.

• ·Your church owns its data. Owners can export the entire church (people, giving, groups, events, content) as JSON/CSV at any time, and can import from Planning Center, Breeze, Church Community Builder, Rock RMS or CSV.
• ·Built-in tooling for data-subject requests: per-person data export and a right-to-erasure tool that anonymises a person while retaining the financial records tax law requires.
• ·Deleted records go to a 30-day Recently Deleted area with one-click restore; soft-deleted people are purged after 90 days.
• ·Email and SMS addressed to a child under 13 are blocked across the platform — messages, group email and SMS, event and volunteer mail (a child with no birth date recorded is treated as under 13). How long children’s records are kept, and how a parent can see, correct or delete them, is set out in our children’s data statement.
• ·We publish our list of subprocessors and offer a standard Data Processing Addendum to every customer at no charge.

Holy has five optional AI features: questions about your dashboard figures, natural-language list building, a short summary of one person’s involvement for a pastor, transcribing a sermon recording (Amazon Transcribe, inside our own AWS account), and turning a sermon you have already preached into follow-up material. That is the complete list — nothing else in the platform sends your data to an AI service.

• ·One switch turns all of it off for your church, with no loss of any other function. While it is off, nothing is sent to any AI service.
• ·Your data is never used to train a model.
• ·Holy’s AI features don’t process the personal data of anyone recorded as under 18, or whose age isn’t on file — judged by the date of birth on file or, when none is recorded, by a child record, a school grade from pre-K to 12th, or a household role of child or dependent; someone with no date of birth, no school grade and no household role has no age on file: the person summary is refused for them, and our AI connector (MCP) leaves their records out. This covers Holy’s own AI features and connector, not integrations a church builds on our REST API. (Email and SMS use the separate under-13 rule above.)
• ·Each feature sends only what it needs, and the platform tells you per feature exactly what that is. The dashboard assistant is sent totals and trends — never names, contact details or individual gifts. List building is sent your own tag and category names — never person records. The person summary is sent a first name, attendance and serving figures, giving totals (only to someone allowed to see giving) and shared notes — never a surname, contact details, birth date, medical or household records, or pastoral notes.
• ·AI features hand back a draft for someone to read, edit or throw away. The one exception is sermon transcription, which saves the transcript to the sermon you asked it to transcribe, where it can be edited like any other text.
• ·A machine-written transcript is marked as machine-written, and is labelled as such where a church website publishes it.
• ·Every AI request is recorded in your audit log — who ran it, which feature, and how much it used. What was asked and what came back are not recorded.
• ·We do not use AI to score, rank or predict the behaviour of individual members.

We are candid about where we are. Holy is not yet SOC 2 or ISO 27001 certified. Our infrastructure providers hold their own attestations (AWS — SOC 1/2/3, ISO 27001; Supabase — SOC 2 Type II; Stripe — PCI DSS Level 1 service provider). We have not started a SOC 2 programme and no audit is in progress; we will pursue one when a customer’s procurement requires it. In the meantime our CSA CAIQ v4.1 self-assessment, SIG Lite responses, security whitepaper and data-flow diagrams are available on request (see Trust documents below), and we answer customer questionnaires directly.

• ·PCI DSS: SAQ A scope via Stripe’s hosted payment element.
• ·GDPR / UK GDPR: standard DPA with EU Standard Contractual Clauses on request; data-subject tooling built in.
• ·COPPA: under-13 send-block and record controls; parental-consent flows are the church’s responsibility and are supported by the platform.
• ·Accessibility: WCAG 2.2 AA is our target — see the accessibility statement for what we test, what we do not, and how to request an accommodation or a conformance report.

The documents a security review is usually answered from. Each is dated; we re-date a document whenever a statement in it changes. Documents marked “on request” are sent by email — no NDA is needed — to security@holyplatform.com.

• ·Security whitepaper — How the platform is built and run: hosting, tenant isolation, identity, encryption, change management, monitoring, recovery, incident response — and the gaps we have not closed yet. (dated 2026-10-24; on request)
• ·Architecture and data-flow diagrams — System context plus the flow of personal data, payment data (card details go to Stripe, never to us) and children’s data. (dated 2026-10-24; on request)
• ·CSA CAIQ v4.1 self-assessment — Our answers to the Cloud Security Alliance Consensus Assessments Initiative Questionnaire, control by control across all 17 domains. (dated 2026-10-20; on request)
• ·SIG Lite responses — An answer key for the Shared Assessments SIG Lite questionnaire, organised by its risk domains. (dated 2026-10-24; on request)
• ·Children’s data statement — What a church keeps about children, why, who can see it, how long it is kept and how a parent can see, correct or delete it. (dated 2026-10-24; public)
• ·Vulnerability remediation SLA and advisories — Fix windows by severity, and every security advisory we have published. (dated 2026-10-14; public)

Also public: our subprocessors, the Data Processing Addendum, the vulnerability disclosure policy and the accessibility statement.

We welcome good-faith security research. Please read our vulnerability disclosure policy and email security@holyplatform.com. Our security.txt follows RFC 9116, and our remediation windows and published advisories are on the security advisories page.