Security

How Auxilium handles the most sensitive records a ministry holds

Household health circumstances, financial hardship, and prayer requests are among the most private things a person will ever hand an organization. This page says plainly how they are handled.

Read the FAQ

What is actually enforced

Each of these is a property of the code, not a policy document.

Every query is tenant-scoped

Multi-tenancy is enforced at the query itself rather than trusted to a filter someone remembers to add. There is no exception path.

Sessions are hashed, passwords are derived

Session tokens are stored as hashes, so a database copy does not yield usable sessions. Passwords go through a deliberately slow key-derivation function.

Production refuses to run unsigned

Without a session secret, development uses a fixed key with a loud warning and production refuses to issue sessions at all rather than falling back to something guessable.

The rate limiter fails open, on purpose

If the limiter’s store is unavailable, logins are allowed. A broken limiter must never lock a ministry out on the day it matters most.

Pattern this addresses: Availability failures during exactly the crisis the software exists for.

Nothing is hard-deleted

Records are soft-deleted, so a mistaken removal is recoverable and the history of what was known stays intact for the audit trail.

Consequential actions are written down

Eligibility checks, denials, imports, and administrative changes go to an audit log. A member told one thing and then another can point at the record.

Questions worth asking any vendor

Where does the data live?

In a managed relational database owned by your organization’s account, with files in object storage under per-ministry key prefixes. Cache layers hold only derived data and are never the system of record, so losing the cache loses nothing.

Is scoring ever sent to a third-party model?

No. Scoring is rule-based and runs locally to the application. An optional AI feature writes narrative triage notes, and with no key configured it reports that it is not configured — scoring is entirely unaffected either way.

Can we get everything out?

Yes. Records export, and the source file for every roster import is retained so any question about what was imported can be answered against the file that was sent.

What happens when part of the platform is unavailable?

It degrades loudly rather than silently. Without background queues, imports commit inline and signals recompute inline; each fallback is logged. The failure mode to be afraid of is the one nobody is told about.