Cardinal Privacy Policy

Effective date: [EFFECTIVE DATE]
Operated by: [FOUNDER LEGAL NAME], an individual doing business as Cardinal, operating in [STATE]
Contact: [CONTACT EMAIL]

This policy is written for church boards and parents first, and for lawyers second. Where plain words work, we use them. Where we do not do something yet, we say so instead of implying that we do.

The short version

• Your church owns its data. Cardinal stores and processes it on the church's behalf and on its instructions.
• Each church gets its own separate database. One church can never see another's records — the separation is physical, not a software filter.
• Church messages to known children go to their guardians. Every broadcast, reminder, and automated message meant for a known minor is delivered to a parent or guardian instead. (Section 3 is written for you.)
• Giving records cannot be quietly edited or deleted — not by church staff, and not by us working through the app; the database itself refuses. Corrections are visible counter-entries.
• No ads, no analytics trackers, no selling of data. The only cookie is the one that keeps you logged in.
• Cardinal is run by one person. We tell you what that means honestly in section 6.

1. Who we are, and whose data this is

Cardinal is church-management software: a directory of people and households plus events, volunteer scheduling, small groups, giving, forms, and bulletins, run for one church at a time.

The church is the owner and controller of its congregation's data. The church decides what to record, who on its staff may see what, and what messages to send. Cardinal — [FOUNDER LEGAL NAME], doing business as Cardinal — is the processor: we host and operate the software on the church's behalf and on its instructions. If you are a member with a question about why your church records something, ask your church; this policy explains what the software does and what we, its operator, do. Each church remains responsible for its own privacy practices and for whatever privacy notice it gives its congregation — this policy describes Cardinal's operation of the software, not any church's practices.

One church can never see another church's data. Every church's data lives in its own physically separate database on its own database server. There is no shared table of people across churches — "separation" here is not a filter that could be forgotten; it is a database boundary that a forgotten filter or query bug cannot cross. A request to an unknown or inactive web address gets a not-found page, never some other church's data, and a login for one church's site simply does not work at another's.

Where Cardinal is today. Cardinal is a young service. As of the effective date it operates a public demonstration site (demo.cardinalchms.com) and is onboarding its first pilot church at no charge. The demo site contains no real congregation's data: its records are produced by an anonymizer that statistically resamples households, so no demo record maps to a real person.

2. What information the system holds

Everything below is held per church, in that church's own database. The church decides which of these features it uses.

• People and households — names, household membership, relationships (spouse, parent, guardian, and so on), and membership status with its history.
• Contact details — email addresses, phone numbers, mailing addresses, and per-address contact preferences, including do-not-contact flags.
• Dates — birthdays and similar dates where the church has recorded them. Birth dates are optional and are entered by church staff.
• Ministry and volunteering — roles, teams, serving preferences, schedules, and service history.
• Attendance and check-in — service and event attendance, including child check-in and pickup records (see section 3).
• Groups — small-group membership and meetings.
• Form submissions — answers members give to forms the church builds, including uploaded files.
• Giving — gifts, amounts, funds, dates, and generated giving statements. Card and bank numbers are never stored. When online giving is enabled, payment details go directly from the giver's browser to the payment processor (Stripe) and never touch Cardinal's systems.
• Pastoral and confidential records — pastoral care notes, prayer requests, and a separately guarded confidential record holding allergies, medical notes, special needs, and emergency contacts (see section 5).
• Photos and files — stored in the church's own private storage bucket; the database keeps only a reference to each file.
• Accounts and system records — staff and member login accounts, login sessions, a record of changes made in the app that entries can only ever be added to — never edited or removed ("append-only") — and delivery records for communications the church sends (see section 4).

Cardinal collects nothing from the general public. The marketing site at cardinalchms.com is a static page with no scripts, no analytics, and no forms. The only public way to hand the system any data is a church's newsletter signup, described in section 4.

3. Children and minors

This section is for parents. It describes exactly what the software does and does not do for people under 18.

Cardinal is a general-audience service for church administration. It is not directed to children, and we do not knowingly collect personal information directly from children online — information about children reaches Cardinal only from their church.

All information about children enters through the church. Data about a minor is entered by church staff, recorded at the staff-operated check-in kiosk, or brought in through a church-run import. Cardinal has no child-facing app, signup page, or data-collection surface of any kind. In fact, there is no self-service signup for anyone — every login, adult or minor, is created by church staff through an invitation only authorized staff can send.

Who counts as a minor. A person is a minor when their recorded birth date makes them under 18. One honest limitation follows: if no birth date is recorded, the system treats the person as an adult — it never guesses that someone is a child. The protections below therefore depend on the church recording birth dates for its children, and we encourage churches to do so.

Church messages to minors are routed to guardians. Any church communication — broadcasts, automated messages, event and volunteer reminders — whose intended recipient is a known minor is delivered to the minor's guardians instead: routed, not dropped. For example: if the church emails everyone signed up for the youth retreat, a 15-year-old's copy goes to her parents, not to her. One exception: account and security messages — a password reset, or an account invitation for a login the church created for a minor — go to the account's own address, because they must reach the account holder to work.

"Guardian" is defined narrowly: recorded custody relationships (parent, guardian, step-parent, foster parent — current, living, and adult), falling back to the living adults of the child's household only when no custody relationship is recorded. A guardian who has opted out is not contacted; a guardian already receiving the message is not sent a duplicate. If a minor has no reachable guardian, the message is not silently discarded — the situation is flagged to church staff for follow-up. Every routed delivery records both the guardian who received it and the child it concerns, so there is always an answer to "why did I get this?"

Adults-only roles are enforced by the database. A volunteer role marked adults-only (nursery roles, for example) cannot be assigned to a minor — the database refuses, on every assignment path. The automated volunteer-substitute system never contacts minors at all; a coordinator may still personally invite a minor to a role that permits minors.

A child is never recorded alone. The database will not accept a living minor without a living adult in their household — this is enforced at the moment of saving, not left as a data-entry convention.

Minors may hold logins; consent is the church's responsibility. Church staff may create a login for a minor (a teen volunteer, for example), and a minor with a login may state their own serving preferences; actual assignment to serve remains a staff decision subject to the adults-only rule. Cardinal does not verify anyone's age and has no parental-consent workflow. Obtaining whatever consent the law or the church's own policies require — for an account, for communications, for anything else — is the responsibility of the church, as the party creating the account and entering the data.

Photo permission: silence is never treated as yes. Each household carries a photo-permission value with three explicit answers (everyone / adults only / nobody). The software refuses to assume a default: an unset value means "the church has not asked," never "yes." Honestly stated: today this is a recorded value for staff to consult — the software does not yet automatically block the use of a photo based on it, so acting on the answer is the church's editorial process.

The member directory. A church's member directory shows members and regular attenders to fellow members of that church — including minors in a household (name, photo, household). What is structurally protected is the birth date: the directory carries no birth-date field at all, and per-person date visibility defaults to hidden. Parents who prefer a child not be listed should speak with their church, which controls directory inclusion.

Child check-in and pickup. Check-in and pickup records sit behind a dedicated safeguarding permission that is deliberately narrower than ordinary attendance access — a head-counting usher or a ministry leader cannot see which children are present, who dropped them off, or any pickup code. Pickup codes are randomly generated, are never usable to look a child up, and are stripped from the change-history log. At pickup, honestly: the security code releases the child; a collector who is not recorded family is flagged for staff review, not automatically blocked — the final judgment at the door belongs to the humans standing there, and the flag makes sure they ask. Check-in details are structurally excluded from the church's automation tooling, so they cannot leak through automation history. Finally, pastoral-attention signals derived from attendance are adults-only: a child's attendance pattern never generates a care prompt about the child.

4. Email, texting, and your consent choices

Every bulk email identifies the church and carries an unsubscribe link. The system itself appends the church's name, its physical mailing address, and a working unsubscribe link to every bulk email — this never depends on the person writing the message remembering to include a footer.

Consent has two layers, and they never cross. Unsubscribing from a mailing list (for example, the newsletter) removes you from that list only. It never silently blocks everything else — leaving the newsletter cannot stop your giving statements or your account messages. Separately, a global do-not-contact flag on an address stops bulk communications to it entirely. One exception, deliberately: account and security messages — password resets and account invitations — are always delivered, because they must reach you for your account to stay usable and safe.

Bounces and complaints are treated as opt-outs. If an address hard-bounces or its owner marks a message as spam, the system automatically flags that address do-not-contact. Opt-outs are honored twice: when a send is prepared, and again at the moment of delivery — so consent withdrawn even after a message has been queued is still honored.

Unsubscribe links are safe. Each link works only for its own address — it cannot be turned against anyone else, and an email scanner cannot trigger it by accident. Re-subscribing works the same way.

Newsletter signup is double opt-in and stores nothing beforehand. Submitting the public signup form saves nothing to the database. A confirmation link (valid 48 hours) is emailed; only clicking it creates the record and the subscription. Unconfirmed signups leave no trace.

The public forms never reveal who attends. The newsletter signup and the forgot-password form respond identically — in content and in timing — whether or not the address is known, so no one can use them to probe whether a person belongs to a church. Both forms are protected against abuse (no one can use them to flood an inbox), and if that protection ever breaks, sending stops rather than becoming unlimited.

Delivery tracking on bulk email. For bulk sends, the system records per-recipient delivery status, and — when the email provider reports them — whether the email was opened and whether a link was clicked. This exists so the church can see whether its message arrived. It applies to bulk communications, not to account messages, which store no communication record at all.

Who carries the email. Our chosen production email provider is Amazon SES; it is configured but not yet approved to carry real congregant email (see the table in section 7). Bulk and automated messages to known minors are routed to their guardians, never the minor — see section 3.

Text messages: none are sent today. The texting feature exists in the software but is inactive: no SMS reaches any phone carrier or SMS provider. If we enable texting in the future (which requires a provider and US carrier registration), we will update the list of outside services in section 7 first.

5. Pastoral and confidential records

Medical and confidential details are stored apart. Allergies, medical notes, special needs, and emergency contacts live in a separate confidential record, not on the basic person record. It is never loaded by default, and reading it requires an explicit confidential-access grant whose scope covers that specific person — a ministry leader with confidential access sees only their own ministry's people; a pastor's church-wide grant covers everyone. This rule is built into the database itself — every path to the data obeys it, not just the screens of the app — and automated tests keep it from ever being loosened by accident. Creating, editing, or deleting a confidential record requires a church-wide grant — a ministry-scoped role cannot modify any confidential record, even for its own people. One consequence to know: deleting a confidential record is permanent in the live system; there is no undo through the product.

Pastoral notes have author-chosen confidentiality. Each note is marked at one of three levels: visible to pastoral-care readers, visible to pastors only, or private to its author. The base right to read pastoral notes is held only by the care team, pastors, and the system owner role — the church's general Admin role deliberately cannot read pastoral notes. A note cannot be filed under someone else's name; authorship is enforced by the database. Prayer requests follow the same access model. One honest limit: pastoral access is granted per role, not per relationship — a person the church places on the care team can read the church's pastoral notes at the care-team level generally, not only notes about people assigned to them. Choosing who holds those roles is the church's decision, and it is worth making carefully.

Pastoral screens are giving-blind by construction. The pastoral-attention views may not read any giving data — a person's presence or position there can never reveal anything about their gifts — and this ban is enforced by automated tests, not by convention.

The community board keeps confidences. When a member posts to the community board, the author chooses the audience: the whole church, or the pastoral team only. A pastoral-audience post is readable only by pastors, the care team, and the system owner — church admins and staff can neither read it nor remove it, because you cannot moderate what you cannot read. Moderation is after-the-fact and accountable: nothing is pre-screened, removal requires a recorded reason the author can always read, and the moderation record stores the moderator's reason but never a copy of the post body. Post bodies are also deliberately kept out of the change-history log, so a withdrawn pastoral disclosure does not survive in a second copy with a different readership.

Changes are attributed and logged; views are not. Every change made through the application stamps who made it, and a separate append-only audit trail records before-and-after history for changes to people data. That trail is not readable by any church role inside the product — it exists at the database level, accessible only to the operator, for accountability and repair. To be precise about its limits: it records changes, not views — we do not currently log who looked at a record. Community-board post bodies are deliberately excluded from its snapshots, so a withdrawn pastoral disclosure on the board never survives as a second copy. Pastoral notes and confidential records are different: their change history — including the prior contents of an edited or deleted note — is captured in that trail. No church role can read it; it is accessible only to us at the database level.

6. How the data is protected

Everything in this section describes mechanisms that actually exist, followed by honest disclosures about what does not.

Separation by construction. One database per church, on its own server; one private file-storage bucket per church. The request's web address selects the church, an unknown web address gets a not-found page — never another church's data — login sessions are structurally per-church, and links in outbound email are composed per church: one church's members cannot receive links into another church's site.

Authorization lives in the database. Every read and write is checked inside the database itself against explicit permission grants that carry both a permission and its scope. Web requests run as low-privilege database roles that cannot bypass those checks. The application does not re-implement authorization on top; automated tests fail the build on the known ways this discipline can erode. Behind-the-scenes tasks (sending email, generating PDFs, reconciling payments) run with broader access than a signed-in user — but each church's tasks can only ever reach that church's own database, and they apply the same permission rules before touching anything sensitive.

Accounts and logins. Passwords are hashed with argon2id — the method security professionals currently recommend first — and must be at least 12 characters; plaintext passwords are never stored. The browser holds only a random session token in a hardened cookie; the database stores only a hash of it, so a database leak yields no usable sessions. Sessions last up to 30 days; logging out ends the session immediately, and a suspended or removed account's session stops working immediately. Login is protected by per-network-address (IP) rate limiting and a temporary per-account lockout after repeated failures, and login responses are engineered not to reveal whether an email address has an account. Password-reset links are likewise stored only as hashes. We do not currently offer two-factor authentication.

Encryption in transit. Browser traffic is HTTPS with strict transport security. Every connection between the application and a church's database is encrypted, and the application confirms it is talking to the genuine database server before sending anything — it refuses to connect at all rather than fall back to a weaker connection.

Stored credentials. Each church's database credentials are stored only in encrypted form (AES-256-GCM), under a key held solely in the hosting platform's sealed environment — a copy of the control database alone reveals no credentials.

Files. Uploads are validated for type and size and stored in the church's private bucket. There are no public buckets; every read goes through a short-lived signed link (5 minutes) issued only after an authorization check.

Logs and error reports are scrubbed at the source. The logging layer redacts emails, phone numbers, passwords, tokens, and credentials embedded in URLs before anything is written. If error monitoring (Sentry) is enabled, events are additionally scrubbed before leaving our systems: no message bodies, no IP addresses, no screen recording, and the only user identifier is an internal random ID.

Payments. No card or bank numbers are ever stored; card entry, when giving is enabled, happens inside the payment processor's own secure fields, browser-direct to Stripe.

The honest disclosures.

• Cardinal is operated by one person, who holds production access to every church's systems — including the technical ability to connect directly to any church's database for support, maintenance, and repair. Changes made through the application are attributed and logged; direct database access by the operator is not itself separately logged today. A church board should weigh this the way it weighs any administrator or bookkeeper with full access to its records. There is no 24/7 security team; incident response is that one person.
• We hold no third-party security certification — no SOC 2, no ISO 27001 — and have not commissioned an external penetration test. A full internal security audit of the application was performed in July 2026 and its findings were fixed. We will not claim badges we have not earned; this policy will be updated if that changes.

7. Who else handles the data (subprocessors)

These are the outside services that church data reaches, or could reach. "Off by default" means the feature sends nothing unless deliberately switched on; "Dormant" means the code exists but the service is not connected.

Two notes worth a board's attention:

• A member's browser can contact almost no third party. The application's content-security policy restricts browser connections to the church's own site, with narrow exceptions for Stripe's payment fields (when giving is enabled) and image loading over HTTPS — which is how files in the church's own private storage are displayed. No analytics services, no ad networks, no third-party scripts.
• We will update this table, and tell churches, before any pending or dormant service starts receiving personal data.

PDF generation (bulletins, giving statements) happens on our own infrastructure — no third-party document service ever sees church data. Giving-statement emails contain a link into the app, never the statement itself, so the email provider learns that a statement exists, not what is in it.

8. How long data is kept — and export and deletion

People are hidden, not erased ("the departed rule"). Removing a person is a permission-gated action reserved to church administrators, and it is a soft removal: the person disappears from every screen and from every forward-looking action — scheduling, invitations, mailing audiences, automated follow-up — but their history remains: giving, attendance, service records, and the audit trail. The same principle applies when a death is recorded: the record is retained, the person is excluded from all future actions, any login session ends, their community posts remain as history, and giving statements are still produced (including to an estate).

Financial records are permanent, on purpose. The giving ledger cannot be edited or deleted by anyone — church staff, us, or automated jobs; the database itself refuses. Corrections are made as visible counter-entries (a void or a refund record). This means a deletion request cannot erase a person's giving history: the integrity of the church's financial records, receipts, and statements depends on it.

Individual erasure requests. We do not currently offer an automated way to hard-delete or anonymize one person's history inside the product. A member's request should go to their church, which controls the data; the church can soft-remove the record as above (hidden everywhere, history retained). Anything beyond that is a manual operation handled case-by-case with us, and financial and audit records are retained by design regardless.

The audit trail is kept indefinitely. It is append-only and we do not currently have a time-boxed purge for it.

Files. Removing or replacing a photo or attachment in the app hides it but does not currently erase the underlying stored object; objects remain in the church's private bucket — reachable only through short-lived authorized links — until we delete the bucket as part of offboarding, a manual step we perform, not something the automated destruction does (see "Church offboarding" below).

Export — leaving with your data. Today, export is a manual process: on a church's request, we will produce a complete copy of the church's database and its uploaded files. A self-service download is designed but not yet built; until it exists, ask and we will provide the export.

Church offboarding — full deletion. When a church leaves and asks us to delete its data, its entire database is destroyed. In detail:

• What it takes to trigger it. Destruction cannot run by automation: it requires an explicit production opt-in naming the exact church, and the operator must review live record counts and type the church's name back interactively. We will not destroy a church's data without the church's written confirmation, and we offer a manual full export first — though honestly, today the pre-deletion export and any waiting period are steps we perform by hand, not safeguards the software enforces.
• Deletion has two dates, and we state both: gone from live systems immediately; copies inside the database provider's automatic backups expire as the roughly 10-day retention window ages out.
• The file-storage bucket is deleted as a separate, manual offboarding step — the automated destruction does not remove it, so we perform this step ourselves and confirm it to the church.
• What survives is exactly one administrative record: an append-only entry noting that the church existed and was deleted, and where its database and bucket lived — never any secret and never any member data — so the deletion itself stays provable.

Suspension. A church can be suspended (for example at its own request): within about a minute its site stops serving entirely, with all data intact, until it is reactivated or offboarded.

9. Backups — and what happens if something goes wrong

Backups today. Each church's database is backed up automatically by our database provider: a daily full backup plus a continuous record of changes, retained for roughly 10 days, with point-in-time restore. Because every church has its own database server, a restore affects only that church. Honestly stated: these provider backups are currently the only backup layer. An additional Cardinal-operated backup (which would also power self-service export) is designed but not yet built; this policy will be updated when it ships.

If we have a security incident. If we confirm a breach affecting a church's data, we will notify that church without undue delay after we discover it — and in any case within 72 hours of discovery. The notice will say, as best we then know: what happened, what data was involved, what we have done, and what we recommend the church do. The church, as the data's owner, leads any notification of its members, with our full help. Consistent with section 6: incident response is one person, and the architecture is deliberately arranged so that an incident in one church's database or storage is structurally contained to that church. An incident in the shared application platform itself, which serves every church, is the case this containment cannot cover — one reason its secrets are held sealed at the hosting platform.

10. Cookies and tracking

• One cookie. The only cookie Cardinal sets is the session cookie that keeps a signed-in user logged in. It is locked to that church's own site, inaccessible to scripts, sent only over HTTPS, and expires after at most 30 days or at logout.
• No analytics, no advertising, no fingerprinting. There are no analytics scripts, no ad trackers, and no third-party scripts on church sites — and the content-security policy enforces this in the browser rather than leaving it to promise. Cardinal sets no cookies on the marketing site.
• Email tracking, restated. The one form of tracking that exists is on bulk church email: delivery status and, when the provider reports them, opens and clicks — described in section 4.

11. Changes to this policy

When this policy changes, we will update the effective date at the top and notify each church; material changes get at least 14 days' notice before they take effect, matching Section 19 of the Terms of Service. Prior versions are available on request. Where this policy says something is "designed but not built," shipping it will come with a policy update, not a silent change.

12. Contact

[FOUNDER LEGAL NAME], doing business as Cardinal

[CONTACT EMAIL]

Members: for questions about your own information, start with your church — it owns and controls its records, and most requests (corrections, removal from the directory, contact preferences) are its to act on. For anything about the platform itself, contact us at the address above.