A pastor's database holds religious affiliation, attendance at religious services, donations to a religious organisation, family relationships, and information about children. Every one of those categories is treated as sensitive or special-category data under Australian, UK, and EU law. We design Pastor HQ around that reality from the ground up — not as a compliance tax bolted on later.
Encryption
In transit
All HTTP traffic is served over TLS 1.2 or higher. HTTP Strict Transport Security is enforced at the edge so a compromised network can't downgrade a connection. Internal service-to-service traffic is also encrypted.
At rest
The primary database (Supabase) encrypts every block at rest with AES-256. On top of that, the most sensitive fields — ChMS OAuth credentials, webhook authenticity secrets — are envelope-encrypted with per-payload Data Encryption Keys (DEKs) that are themselves wrapped by long-lived Key Encryption Keys (KEKs) held in AWS KMS in the Sydney region. The EncryptionContext binds every payload to its owning church, so a row leaked from one tenant cannot be decrypted by claiming a different tenant.
Access control
Tenant isolation
Every table that holds church data has Postgres row-level security policies that scope reads and writes to the user's own church. The policies are enforced by the database, not the application — any new query path automatically inherits them.
Role model
Two application roles: member and super_admin. The split is deliberately small — most churches don't want to manage a complex permission matrix. Donation tables additionally require multi-factor authentication (AAL2) at the row-level, so a compromised password alone never grants access to giving data.
Engineering access
Pastor HQ engineers do not access customer data in the normal course of operations. When access is required for a specific support case, it is logged, auditable by the customer on request, and limited to the resources needed for the case.
Network and infrastructure
- Edge / app: Vercel, with deployments pinned to the closest available region per request and the apex domain protected by HSTS.
- Database: Supabase (Postgres) in
ap-southeast-2(Sydney). No public network access — connections route through Supavisor pooling. - Key management: AWS KMS in
ap-southeast-2. The IAM user that holds operational access is scoped to a single key ARN with the minimum verbs needed to encrypt and decrypt; it has no console password and no access to other AWS services. - Background jobs: Inngest. Function payloads carry only IDs; sensitive data is fetched fresh from the database within each job.
- Observability: Sentry. PII scrubbing is applied before events leave the application; we configure Sentry to not retain raw request bodies.
Webhooks
Webhook deliveries from connected ChMS providers are verified with HMAC signatures before any side effect. The per-subscription secret is envelope-encrypted at rest and decrypted only at verification time. A failed signature returns a 401 with no body and never triggers a sync.
Audit logging
Every read or write of customer data emits an audit record with the actor, action, resource, and timestamp. Audit logs are retained for 12 months and can be exported to a customer church on request. We use the same audit log for our own internal review.
Backups and recovery
- Daily encrypted database backups, cross-region for redundancy, on a 35-day rotation.
- Point-in-time recovery on the primary database covers the previous 7 days.
- Recovery procedures tested quarterly; the most recent successful drill is recorded internally and available to customers under NDA.
Incident response
We commit to notifying affected customers within 72 hours of confirming a breach of Personal Data on our systems. Notifications include the categories of data involved, the approximate scope, the remediation in progress, and any action the customer should take themselves. We do not unilaterally notify regulators on the customer's behalf — Customer is the data controller — but we provide whatever evidence the customer needs to do so.
AI features and provider posture
Pastor HQ uses third-party AI providers (currently Anthropic) for opt-in features such as sermon-prep assistance and target-setting suggestions. These features are off by default on every new tenant. When a church enables them, only the content the church explicitly submits is sent to the provider — never bulk member data, never donation history, never pastoral notes — and the provider is bound by a written agreement that prohibits using that content for model training.
Anthropic Zero Data Retention (ZDR): pending signature. AI features that would require provider retention are disabled platform-wide until the ZDR addendum is in place. If you have a church use case that depends on AI features being live, write to security@pastorhq.comand we'll let you know when the addendum lands.
Compliance
- Australia: Australian Privacy Act 1988 + 13 Australian Privacy Principles. Statutory privacy tort (commencing June 2025) acknowledged.
- UK / EU: GDPR / UK GDPR commitments described in the Data Processing Addendum.
- SOC 2 / ISO 27001: not yet certified. We are operating against the control framework with the intent to pursue Type 1 once revenue supports the audit cost. Customers requiring formal attestation today should contact us — we can share our internal control documentation under NDA.
- Children's Online Privacy Code (Australia): applies from 10 December 2026. Our kids check-in feature roadmap will land any required changes ahead of that date.
- Automated Decision-Making transparency: applies from 10 December 2026. AI features are opt-in, off by default, and never make decisions with legal or significant effects without a human in the loop.
Responsible disclosure
If you believe you've found a security issue in Pastor HQ, please email security@pastorhq.com. We'll acknowledge within one business day and keep you updated through to resolution. We do not currently offer monetary bounties; we do publicly thank researchers (with permission) once a fix is shipped.
Contact
Security enquiries, attestation requests, or DPA modifications: security@pastorhq.com.