Security & trust
Confidential pastoral care that's actually confidential.
Epimely holds some of the most sensitive information a church keeps — who is grieving, who is in crisis, who asked for prayer in confidence. We designed the system so that protecting that information is not left to good intentions. This page describes how it actually works, so your board, your insurer, or your IT team can see the architecture rather than take our word for it.
Envelope encryption, per church
Sensitive fields — care and prayer request contents, requester email and phone, intake answers — are encrypted at rest with AES-256-GCM, an authenticated encryption standard. Each church has its own data-encryption key, and that key is itself wrapped by a separate master key. A fresh random nonce is generated for every value, and the authentication tag is verified on every read, so tampered ciphertext fails to decrypt rather than returning corrupted data.
Default-deny access
Signing in grants almost nothing on its own. Access to each record is decided individually — by a person's role, by whether the record is assigned to them, and by explicit, approved access grants. When access is denied, the record simply does not exist as far as that user is concerned, rather than advertising that something is being hidden.
Sealed confidential requests
A request marked confidential is visible only to pastors and above and is sealed at the database. Its contents are not decrypted for anyone else, and it does not even appear in another user's list. The seal is enforced on the server, not by hiding fields in the browser.
Redaction for triage
Staff whose job is to route incoming requests can see the queue with requester names, emails, and phone numbers redacted to initials. That redaction happens on the server before the data is ever sent to the browser — there is no full copy waiting behind a CSS rule.
Just-in-time admin elevation
Administrators work day-to-day with the same limited scope as any care worker — only what is assigned to them. Organization-wide reads, the audit log, and granting or revoking access require deliberate elevation: re-authentication that opens a short, 30-minute window. Every elevation is recorded.
Hash-chained audit log
Reads of personal information and care notes, status and flag changes, access grants, and elevations are written to a tamper-evident audit log. Each entry is cryptographically chained to the one before it, per church, so the history of who saw what — and when — cannot be quietly rewritten. The chain can be verified, and a church's administrators can review it.
Strict tenant isolation
Every record carries the identity of the church that owns it, and every query is scoped to that church. One church's data never sits beside another's, and there is no shared view that crosses the boundary. Database foreign keys enforce that records cannot be linked across churches.
Hardened sessions and uploads
Passwords are stored only as strong one-way hashes. Sessions use short-lived access tokens with rotating refresh tokens that detect reuse. File uploads are checked by real content inspection, not just their extension, and active content types are rejected. The platform runs behind standard transport-layer encryption.
Reporting a concern
If you believe you have found a security issue in Epimely, please tell us at [email protected] before disclosing it publicly, and we will work with you to address it. Churches that need a data-processing addendum or a formal description of our infrastructure and sub-processors can request one from the same address. See also our Privacy Policy and Terms of Service.