Security

Last updated: July 12, 2026

1 · Our approach

We treat your church's, household's or organization's data with the same care we'd want for our own. Security isn't a document — it's the reason the policies on this site can be honored in practice.

2 · Encryption

All traffic travels encrypted in transit (HTTPS/TLS); there are no unencrypted routes in production. Data at rest is encrypted by our database provider (Supabase, on PostgreSQL).

3 · Multi-tenant isolation

Every organization and every household is isolated at the database row level (PostgreSQL Row-Level Security): no user can read or write data belonging to an organization or household they don't belong to, regardless of which URL or parameter they use.

4 · Passwords and authentication

Passwords are never stored in plain text; our authentication provider stores them hashed (bcrypt) and salted. We offer Google and Apple sign-in as alternatives. Two-factor verification is available and mandatory for organization admin accounts.

5 · Secrets management

API keys and credentials live in environment variables, never in source code. Every push and pull request runs an automated secret scan (gitleaks) that blocks the merge if it detects an exposed credential.

6 · Backups

The database has automated, periodic backups managed by Supabase, with retention sufficient for incident recovery.

7 · Least-privilege principle

Production access is limited to those who need it to operate the service. Each role's access within the apps (secretary, treasurer, pastor, administrator) is defined explicitly in the database, not just in the interface.

8 · Responsible vulnerability disclosure

If you find a vulnerability, report it to support@adventpro.org with the subject “Security” before disclosing it publicly. Please do not access, modify or exfiltrate other users' data while testing. We will acknowledge receipt and keep you updated on progress.

9 · Incident response plan

If a security breach occurs, we follow five steps: contain (revoke access, rotate credentials), assess (which data and how many users were affected), notify (competent authorities within 72 hours where GDPR requires it, and affected users without undue delay when the risk is high), document the incident, and remediate the root cause.

10 · Changes to this page

We update this page when our security practices change, with the date at the top.

Found a vulnerability? Write to us at support@adventpro.org

Security · AdventPro