Security
One church cannot see another. Here is the rule, not the promise.
Every church software vendor says your data is safe. This page is for the trustee or elder who would rather check than take our word: what the database actually does, quoted rather than described, and what we test, and how often.
The boundary is in the database, not in the screens
Most software decides what you may see in the interface: a menu is hidden, a button is greyed out, a page checks your role before it draws. That works until somebody goes around the interface, which is one clever URL away. Fold does not rely on it. Every table of church data carries rules that Postgres itself applies before it returns a single row, whoever is asking and however they ask.
This is the rule on the giving table, exactly as the database holds it. A row is returned only if:
org_role(organization_id) = ANY (ARRAY['super_admin', 'pastor', 'admin', 'minister', 'finance_officer']) OR oversees(organization_id)
In plain words: you see a church’s giving if you hold one of those five roles in that church, or if you lead a body above it in the denomination and are looking down. A class leader is not on that list, so a class leader asking the database for giving, by any route, gets nothing. Not an error, not a blank screen with a hint. Nothing.
There are 62 rules like this across 22 tables. Oversight from above is read only by design: a regional overseer sees every assembly beneath them and cannot write into one.
We attack it after every change
A rule is a claim until something tries to break it. After every deployment, a script signs up a throwaway account and tries to do the things that must not work. It fails the deployment if any of them succeeds. Among what it tries:
- The public key cannot read any of the 22 tables, including members, giving, payments and invoices.
- A signed in stranger with their own account, targeting a real church by its id, sees nothing.
- That stranger cannot insert themselves into a church as its pastor.
- That stranger cannot raise an invoice against a church they do not belong to.
- The dashboard totals and the roll ups return nothing across a church boundary.
- SQL injection through every filter is refused.
- Every private page refuses an unauthenticated request.
- The Paystack webhook refuses an unsigned or forged signature.
- No secret appears anywhere in the delivered HTML.
Ninety checks in all. The throwaway account is created at an address that can never receive mail and deleted afterwards, and nothing is ever written to a real church.
The rest, briefly
- Your money never touches ours
- Each church has its own settlement account with Paystack. A tithe paid by mobile money is paid to you, and it never enters Fold's balance. We do not hold your account number: Paystack does, and we keep a reference code and a label.
- Every change is on the record
- Who added a member, who changed a status, who recorded or corrected a gift, and when. The log is written by the database, not the app, and nobody can edit or delete an entry, including the pastor reading it.
- Sign ins are watched
- Five failed attempts against one address in fifteen minutes and that address is paused. Every attempt, successful or not, is recorded in a log nobody can read through the API. A password change ends every other session.
- Your records are yours
- Export your register as a spreadsheet whenever you like, without asking. Close the account and everything is deleted within thirty days. Under Ghana's Data Protection Act, 2012 (Act 843), your church is the data controller and we build to that.
- What we do not claim
- Nothing here is a guarantee against every possible attack; no honest vendor can offer one. It is a description of what the boundary is, where it lives, and how we know it holds today.
Questions a trustee would ask that this page did not answer: ask them, and we will answer in writing.
See it with your own register
Thirty days free, no card, and your records leave as easily as they arrive.