Audit and logs

The audit is the system that records what happens within the platform in an immutable and queryable way. It is the foundation that supports SOC 2 attestations, reports to data protection authorities, and the church’s own internal reviews.

What is logged

Every critical action leaves a record in audit_logs with:

Who (user + role at the time of the action).
What (affected entity and type of change).
When (UTC timestamp with milliseconds).
From where (IP, user agent).
Change data (before and after state for sensitive entities).

Covered actions

Category	Events
Authentication	successful login, failed login, logout, password change, MFA activation / reset.
Permissions	user invitation, role change, campus scope change, deactivation.
Personal data	creation, edit, and deletion of members, households, and prospects.
Financial data	batch creation, batch close, tax-deductible receipt issuance, Stripe connect / disconnect, payment execution.
Sensitive data	access to PHI fields (HIPAA), access to minors’ data (COPPA), download of sensitive files.
Configuration	changes to church settings, branding, privacy policy, subscription.
Integrations	connect and disconnect, sync errors, credential changes.
Exports	bulk downloads of personal or financial data.

Append-only

The log is append-only: only adding entries is allowed. Nobody, not even super_admin or the Ministrium technical team, can modify or delete past entries.

How it’s enforced:

The audit_logs table has no UPDATE or DELETE endpoints exposed.
Postgres Row-Level Security policies deny modification operations even to the backend’s technical role.
Each entry includes an integrity hash chained with the previous entry; altering one would break the chain and be detected at the next integrity check.
A nightly job verifies the entire chain and emits an alert if it finds inconsistencies.

This combination (RLS + chained hash + periodic verification) is defense in depth: even if someone managed to execute arbitrary SQL, an alteration of the log would be detected within 24 hours.

Retention

7 years mandatory retention, in compliance with financial regulations (tax-deductible receipts) and SOC 2.
After 7 years, the church can request final export and deletion, or extended retention.
Old logs are moved to cold storage after 12 months without changing their accessibility — only the cost and query response time change (from milliseconds to seconds).

Who can query the log

The Audit module in the side menu is available for the roles:

admin — entire church.
pastor — entire church, without detailed financial actions.
accountant and finance — all financial actions.

Other roles don’t see the log, although their own actions are logged. This is deliberate: the audit is a governance tool, not an operational view.

Filters and search

From the Audit module you can filter by:

Date range.
User (who performed the action).
Event type (login, member edit, batch close, etc.).
Affected entity (a specific member, an event, a batch).
IP or user agent.
Free text on the change data.

Filters combine with AND.

Export

Any filtered view can be exported in:

CSV — to open in a spreadsheet.
JSON — to import into SIEM or BI tools.

Exports are themselves audited events (a record is kept of who exported what and when).

SIEM integration

For churches or denominations that operate their own SIEM (Security Information and Event Management), we offer:

Outbound webhook that sends each audit event to the URL the church configures.
Standard Splunk / Datadog / Elastic connector under enterprise plan.
Audit API documented in API Reference.

What is not logged

By design:

Passwords in plaintext. We only record that there was a password change, not the password.
Content of private pastoral messages. We record that the message was sent, not its text.
Card payment information. We don’t process it; Stripe does.

Next steps

SOC 2 — the external audit that validates these controls.
Encryption — how the log itself is protected.
GDPR and LGPD — how the log supports data subject rights.