Data Encryption

ChurchDek uses industry-standard encryption and access controls to protect church data. Encryption is one layer of defense alongside tenant isolation, RBAC, audit trails, and secure development practices.

All connections to the ChurchDek web application and APIs use TLS (HTTPS). We enforce modern cipher suites and redirect insecure requests where applicable.

Integrations with payment gateways, SMS providers, and email services use TLS for API calls. Webhook endpoints require HTTPS in production.

Production databases and object storage rely on provider-managed encryption at rest (AES-256 or equivalent). Disk volumes on application servers are encrypted at the infrastructure layer.

Sensitive configuration such as API keys and gateway secrets are stored in environment-specific secret stores, not in source code.

User passwords are hashed with strong one-way algorithms; plaintext passwords are never stored. Session tokens are HTTP-only cookies where supported, with rotation on privilege changes.

Optional email verification and rate limiting reduce credential-stuffing risk on login endpoints.

Database backups are encrypted in transit to backup storage and encrypted at rest in the backup provider. Access to restore operations is restricted to authorized operations staff.

Application queries scope data by tenant identifier. Middleware and model traits enforce tenant boundaries so one church cannot read another’s records through normal API use.

Churches should use strong unique passwords, limit admin accounts, and protect devices used for check-in and finance. Exported spreadsheets and reports should be stored and shared securely by your team—encryption in ChurchDek does not extend to copies you download locally.

Security questionnaires and encryption attestations for procurement are available on request: contact@tecunitgh.com with subject “Security”.