aVillageSecurity & privacy
The strictest thing in the app is what it won't show you
Foster care puts children into someone else's software during the least private season of their life. Most of the design decisions below cost a feature somewhere, and were made anyway.
The line
A child's details are visible to one account: their family's
The household roster — a card for every person at home, including foster placements — carries names, birth dates and photos. That table is readable only by the account linked to that family. Not church staff. Not a campus leader. Not other members. Not another church.
This is deliberately stricter than the rest of the app. Family cards and check-ins are visible to leaders, because that's what a ministry is for. The roster is not, because a leader's job never required a six-year-old's birthday.
- A child's name is optional — the app renders the relationship when it's blank, and the Privacy Policy promises we never require it
- Photos are in a private bucket with per-owner storage rules and are served through links that expire — never a public URL
- A family's own history is never purged by the retention job, even when other data expires
Enforced where it can't be bypassed
Access rules are row-level security policies in Postgres, not checks in the app. That distinction matters: a request that skips the interface — a script, a stale token, a bug in a screen — is refused by the database on the same rule.
Every migration that adds a table or touches a policy has to extend the test suite that runs against a from-scratch database on every change, and the suite fails the build if any public table is missing its policies.
The rest of it
What else is locked down, and why
Report and block, everywhere
Every member-visible surface can be reported, and reporting offers to block the author in the same step. Blocking is refused on the server for 1:1 messages — not merely hidden in the interface.
Texts need proof, not a checkbox
A number can't be opted in to SMS until that number has been verified. Changing the number drops the opt-in. A direct API call is refused exactly as the app refuses it.
Export that respects the boundary
A member downloads their own account; a leader exports the community. A member's export never contains a leader's private notes, and a community export never contains a family's household roster.
Retention with a published clock
What expires and when is written in the Privacy Policy, and one nightly job deletes exactly that. It never touches a family's own history, or a financial or consent record.
Reporting sees totals, not people
Cross-community aggregation happens only in gated server functions and only aggregates ever come back. No row about a family or a child is in any report or export a platform operator can run.
Responsibility isn't permission
Naming a leader as a family's point person records who is checking in. It grants that leader nothing — the access rules are byte-for-byte unchanged.
Plainly
What aVillage does not do
- We do not sell data, and we do not share mobile numbers or consent records with third parties.
- We do not run background checks. The app records what your leaders verified; it never performs a check itself.
- We do not track which screens a member visits. App-open counts exist as a frequency signal, are readable by nobody as raw rows, and leave the database only as aggregates.
- We do not show a family's coordinates to anyone. Community search is scored deterministically and never on a family's location.
- We do not pause access to your data over money. A billing hold never touches data, and export and deletion stay reachable under one.
Common questions
Where does the data live?
In a managed Postgres database with row-level security, plus private object storage for photos and documents. Payments are processed by Stripe; card details never reach aVillage's servers.
Can a leader see a family's private notes to their circle?
A care circle's content is visible to the circle, the family, and church staff — that's the scope a circle is defined with, and it's stated in the app when a family posts into one.
The household roster is the surface that is genuinely private to the family, and it's the one carrying a child's identifying details.
What happens if we leave?
Export the community as a document at any time, from inside the app, including while a billing hold is in place. Members can export and delete their own accounts independently of the church.
Can we loosen the rules for our ministry?
The roster's restriction is a code-level policy, not a setting — loosening it would be a deliberate change to the product, not a toggle a church can flip. If your ministry has a real need there, tell us; we'd rather have the conversation than ship a switch.
How do you handle abuse reports?
A report goes to your church's own moderation queue, where staff can remove the content. Removal genuinely deletes it — every reportable content type has a matching removal path, and a test pins those two lists together so one can't be widened without the other.
Questions we haven't answered here?
Ask. Security questions from a church get a real answer from a person, not a PDF.