Security & Compliance
How we protect the information members, attendees, and organizers trust us with across the AIsaiah app and the Shiloh events platform, what we store, and where we still have work to do.
Last reviewed September 24, 2026. Updated whenever a control changes.
Where we are. Our infrastructure providers hold SOC 2 Type 2 and ISO 27001 attestations, listed below with links to their own compliance pages. The Aisaiah Foundation’s own platforms are not yet independently certified. The controls on this page are live in production today; the roadmap lists what is still in progress.
Where your data lives
| Provider | Role | Region | Attestations |
|---|---|---|---|
| Supabase (PostgreSQL) | Events platform database and file storage | US East (N. Virginia) | SOC 2 Type 2 · ISO 27001 · AES-256 at rest · TLS in transit |
| Google Firebase | Sign-in, the AIsaiah mobile app, daily readings | United States | Google Cloud compliance program |
| Fly.io | Events platform API servers | US East (Ashburn) | Provider security program |
| Cloudflare | Websites, TLS, DDoS protection | Global edge | Trust Hub compliance resources |
What we collect
- Identity
- Name, email address, chapter or community, and your CFC member ID when you link it in the app.
- Spiritual practice
- Your prayer, reflection, and service check-ins and settings in the AIsaiah app. Reflections you write are yours; we do not sell data and we show no advertising.
- Events
- Registrations, household groupings, and the time you checked in to an event.
- Participation
- Session questions, feedback survey answers, and photos you choose to upload to an event gallery.
- Not collected
- Payment card data. Event payments are handled by the organizer’s payment provider, never by our platform.
How it is protected
Row-level security on every table
All events-platform database tables enforce row-level security. Tables holding personal data accept connections only from our API server; no browser or app key can read them directly.
You can only read your own data
Requests for a person’s registration, check-in status, household, or photos require a verified sign-in token and are limited to you and the household you registered with.
One account per member
A CFC member ID can be linked to a single sign-in. Attempts to claim a member already linked elsewhere are refused and recorded.
Append-only audit log
Security-relevant actions such as check-ins, account links, and refused access are written to an audit log that is never edited, retained for 24 months, then purged.
Hardened edges
HTTPS everywhere, a strict browser-origin allowlist, per-address rate limiting, and secrets held in the hosting provider’s secret store rather than in code.
Published content only
Public event pages, agendas, and galleries expose only what an organizer has published. Draft events are unreachable by guessable links.
What is in progress
- Enforce the write gate so every write to the events API requires a signed-in or kiosk credential (currently in monitoring mode).
- Retire the legacy v1 events API once its remaining caller is migrated.
- Automated cross-chapter and cross-attendee isolation tests on every deploy.
- Written security policies, access reviews, and an external SOC 2 readiness assessment for the platform itself.
Report a concern
If you believe you have found a security issue, or you want data about you corrected or removed, tell us and we will respond. Please do not access other people’s data to demonstrate a problem; a description is enough.