Privacy Policy

Citizen Sites LLC (“Citizen Sites,” “we,” “us,” or “our”) is a United States limited liability company, and it is the entity responsible for the information described in this policy. Citizen Sites is a hosted software platform that helps churches build and run a public website. The platform includes a page editor, a signed-in portal for the church owner, support for a custom domain the church already owns, a forms tool with optional Planning Center person-push, a two-way Google Calendar surface, a prayer board with magic-link team viewers, sermon videos the church hosts on its own YouTube channel, form-submission and published-site analytics, and connections to a small set of external apps.

When a church signs up with Citizen Sites, that church is the “Customer” or “Tenant.” The Customer controls the personal information of its members, prayer-team viewers, form submitters, and visitors (the “End Users”). For that information Citizen Sites acts as a service provider / data processor on the Customer’s behalf. End Users with questions about their personal data should contact their church directly first.

Yes, we collect personal information. Any software that signs people in, takes form submissions, and sends email does, and a policy that implied otherwise would be worthless. Section 3 lists every category in full. What we hold ourselves to is narrower than the law requires: we collect only what a feature actually needs, we use it only for the purposes in § 4, we do not sell or share it, we do not use it for advertising, and we do not train AI models on it (see § 18). Where the California Consumer Privacy Act as amended, the other U.S. state privacy laws listed in § 16, or the GDPR and UK GDPR apply to a given person’s information, we honor the rights those laws give them, and we honor the same requests from people whose local law grants them nothing.

This policy applies to information collected through:

• Our marketing website at buildcitizensites.com.
• The Citizen Sites authoring surfaces: the page editor, the signed-in owner portal, and our internal admin console.
• Published tenant church websites we host, including a custom domain the church has pointed at our infrastructure.
• Forms and prayer-request forms on published tenant sites, including Planning Center form embeds we serve through the platform.
• The public prayer-team landing page accessed by a tenant’s invited viewers via magic-link tokens.
• Email and other direct communication you send us.

This policy does not cover third-party websites we link to but do not operate.

Church owner account & authentication

Each tenant church has one owner account. When the owner signs up we collect their name, email address, password (stored only as a salted hash by Firebase Authentication), the church name, and the identifiers we need to scope their access to their own tenant. We also issue a signed session cookie so signed-in pages know who you are. Our authoritative authorization signal is a JSON Web Token custom claim (churchId + role) on the owner’s Firebase identity.

A signup that has not yet completed payment and verification is held in a short-lived pending record that expires automatically after one hour.

Site design & uploaded media

Your site is stored as a set of JSON design documents: site-wide settings (colors, typography, button presets) plus one document per page. A church can keep more than one named design, with one of them active. We also store the images, custom font files, video links, and other media the church uploads. Uploaded media and fonts live in Firebase Storage, scoped to the design they belong to, so deleting a design deletes its files. When you publish, the compiled site is written to a Google Cloud Storage bucket.

Each time a publish goes live we save a copy of the design it was built from so the owner can restore it. We keep the most recent 25 copies per design in Google Cloud Storage, and older ones are deleted automatically as new ones are saved. Deleting a design deletes its saved copies with it. Pressing Preview instead compiles the site in memory on the server handling that request and keeps nothing.

Web fonts you choose are fetched from Google Fonts at publish time and copied into your published site, so your visitors download fonts from us rather than from Google. Google receives a request from our servers when we mirror a font, not from your visitors’ browsers.

Where these files live, and which of them are public

Everything we hold for a church sits in one of three places, and they are not equally private. It is worth knowing which is which before you upload something.

• Your published site is public, because a website is public. When you publish, the compiled pages, stylesheets, scripts, fonts, and every image those pages use are written to a Google Cloud Storage bucket and served to anyone who visits your address. Assume that anything you publish can be read, copied, indexed by a search engine, and archived by a third party you have no relationship with. Removing it from a later publish removes it from your site, but not from anyone’s cache, index, or archive.
• Your media library is reachable by anyone holding the link. Images, custom fonts, and other files you upload are stored in Firebase Storage and each one is addressed by a long, unguessable URL that requires no sign-in to open. That is what lets your published pages load them, and it applies to every file in the library, including one you uploaded and never placed on a page. The library itself cannot be browsed or listed by an outsider, and we do not publish an index of it, so a file is only as exposed as its address is. Treat the library as somewhere you put things you are willing to have seen, and do not upload a document, a directory, a photograph of a minor, or anything else you would not hand to a stranger who asked.
• Everything else is private and requires authentication. Your design documents, your saved publish history, form submissions, prayer requests, calendar data, attendance figures, integration tokens, owner identity, and analytics tallies are reachable only through requests we authenticate and scope to your church. There is no public address for any of them.

All of it is held in the United States on Google Cloud Platform and Firebase. Google encrypts stored data at rest and every connection to it runs over TLS. Access from our side is limited to least-privilege service accounts, and we do not grant public listing on any bucket, so an object is reachable only at its exact path and never by browsing the bucket it sits in.

Forms & submissions

Anything submitted through forms on a published tenant site, and through our own feature-request, custom-design-request, beta-application, and contact forms. We keep per-month counts of form submissions so the owner can see submission volume over time. If a Customer connects Planning Center and enables person-push on a form, the submission is forwarded to their Planning Center People account; the submitting End User’s data is then processed under Planning Center’s own privacy terms.

A Customer can also put one of their own Planning Center forms on a page. To do that we read the definition of that form from Planning Center, meaning its questions and the choices each one offers, and rebuild it on the page. When a visitor fills it in, their answers are sent to Planning Center and filed against that form, including the name and email address Planning Center uses to identify the sender. In that arrangement Planning Center holds the submission and their privacy terms govern it.

Prayer board entries

Prayer requests come from two places: the church owner writing them in the portal, and visitors submitting them through a prayer form on the published site. A visitor submission may include the text of the request, a display name, and optionally an email address or phone number. An email address left on a request is used to tell that person when their request is prayed for or answered, and for nothing else. See § 8 for what happens to a request after it is submitted, including which parts of it can appear publicly.

If the owner invites prayer-team viewers by email, we store the invitee’s name, email address, and a one-way hashed copy of their magic-link token.

Calendar data

When a Customer connects Google Calendar, we exchange OAuth tokens and sync events both ways with the calendars they grant access to. Google Calendar is the source-of-truth: we display its events on the tenant site and in the owner portal, and when the Customer creates, edits, or deletes an event from the portal we write that change back to their Google Calendar on their behalf. We only touch the calendars the Customer selects. Events the Customer manages through the portal are also cached in our database and expire after two years.

Sermon videos & the recordings library

A Customer’s sermon videos stay on the Customer’s own YouTube or Vimeo channel. We never host the video file. When they place one on a page we store the link and whatever title or description they type beside it, and at publish time we download that video’s still frame once and serve it from the church’s own site, so a visitor’s browser is not made to ask a video provider for an image before the page can finish drawing.

A Customer can also connect their YouTube channel to build a recordings library inside the portal. We store which channel they connected and the state of the last sync, and a scheduled job then reads the channel’s public video list and keeps a record per video: its YouTube video identifier, title, description, thumbnail URL, publication date, and the ministry or series grouping the Customer files it under. The groupings are the Customer’s own. This library lives in the portal; nothing about it is written into a published page.

Service attendance

A Customer can turn on an attendance chart and type in how many people attended a service. We store the date, the number, and any label they give it. These are totals for a gathering, never a record of who attended, and the feature is off until the Customer adds it. Deleting the chart deletes the figures.

Subscription billing data

Citizen Sites subscription billing runs through Stripe. Stripe collects the Customer’s card data directly inside Stripe’s PCI-DSS certified environment; we never see or store full card numbers. We store the Stripe customer and subscription identifiers, plan name, billing cadence, trial and renewal dates, and a short-lived audit log of webhook and checkout-fulfillment events used to keep the subscription state in sync.

Citizen Sites does not process online giving, donor payments, or any other money flowing to the church. Tenants who want to take donations should link out to their preferred giving provider; that provider handles donor data under its own policy.

Integration tokens

If a Customer connects Google Calendar, Planning Center, or YouTube we store the OAuth refresh token and the records the integration is scoped to reach. We do not request access beyond the documented scopes in § 10.

Notifications

We generate in-app notifications for the owner (for example a new form submission or a billing warning). These are stored against the church and expire after 30 days.

Logs, telemetry & usage

Web servers and edge caches record IP addresses, user agents, timestamps, and request paths for security, rate limiting, and debugging. Rate-limit counters are keyed by IP and expire within the hour. Our contact form additionally stores a one-way hashed IP address and the submitting browser’s user agent to deter abuse and spam; we cannot reverse the hash to recover the original IP.

We run Vercel Analytics and Vercel Speed Insightson our own platform surfaces only: our signed-in pages and the gateway that serves them. These tools collect aggregate performance and page-view metrics with no advertising identifiers.

We count visits to published tenant sites, and we identify nobody. Every page we serve carries a small first-party script that reports one pageview to our own endpoint. What we store is a per-day tally for that church: how many views and how many visits, and counts by page path, by referring site, and by device type. Nothing about the individual is recorded. There is no cookie, no advertising pixel, no fingerprint, no visitor identifier, and no profile. A visitor’s IP address and user agent are used in the moment to rate-limit the endpoint and to tell a browser from a bot, and are stored nowhere. Whether a pageview started a new visit is a flag the browser keeps in sessionStorage and forgets when the tab closes, so we learn that a session began and never whose. Query strings are stripped from paths before they are counted.

Because there is no identifier, this measurement cannot follow anyone between sites or between sessions, and we do not combine it with any other information we hold. A church sees these counts in its portal alongside a count of its own form submissions over time.

A published site loads no third-party analytics, no advertising pixels, and no external font or script CDNs by default. A tenant may add their own analytics, scripts, or embeds in their site settings; if they do, those tools collect data under the tenant’s own privacy policy, not ours, and the tenant is responsible for any notice or consent that use requires.

• To operate the platform: sign-in, the editor, the publish pipeline, scheduled jobs, and email delivery.
• To bill the church owner’s subscription through Stripe and to manage trials, renewals, and past-due accounts.
• To send transactional email (verification, password resets, prayer-team magic-link invitations, form-submission notifications, prayer-request updates to whoever submitted the request, and billing warnings).
• To count visits to a published church site, without identifying anyone, and report the totals to that church.
• To investigate security incidents, prevent abuse, and rate-limit malicious traffic.
• To improve product reliability through aggregated, non-identifying usage measurement.
• To respond when you contact us.

We do not sell personal information. We do not use End User data for advertising. We do not use it to train AI models, and § 18 says what that commitment covers and what happens if we ever add an AI feature.

Personal information is shared only as required to run the service or as required by law:

• With your church (the Customer). End User data is visible to the church owner on the Customer church account.
• With service providers (sub-processors). See the next section.
• With integrations the Customer connects. If the Customer enables Planning Center person-push, form submissions flow to their Planning Center account. If they connect Google Calendar, event data flows in both directions between Google and our platform.
• Publicly, where the Customer chooses to publish it. Content the Customer places on its site is public by definition. Approved prayer requests can be published on a public prayer wall as described in § 8.
• For legal reasons. Subpoena, court order, or to protect the rights, property, and safety of Citizen Sites, our customers, and the public.
• In a corporate transaction. If Citizen Sites is acquired or merges, customer relationships and the data tied to them transfer with the business under this same policy or a more protective one.

Other companies are involved in running this platform, and they fall into three groups that matter differently to you. We name all three rather than only the first.

Sub-processors: they handle data on our instructions

• Google Cloud / Firebase: authentication, Firestore database, Firebase Storage for uploaded media, Google Cloud Storage for published sites and publish history, and Cloud Tasks queues.
• Vercel: hosting for our own applications, edge caching, image optimization, and the domains API we use to attach a Customer’s custom domain and issue its TLS certificate. Vercel Analytics and Speed Insights run on our own signed-in surfaces, never on a published church site.
• Stripe: platform subscription billing for the church owner. (Citizen Sites does not operate Stripe Connect and does not process donor payments.)
• Resend or AWS Simple Email Service: transactional email delivery. We use one of these two at a time, selected by configuration.

Companies our servers fetch from, without involving your visitors

• Google Fonts: we list available fonts for the editor and download the font files you choose at publish time, then serve them from your own site. Google sees a request from our server, not from your visitors’ browsers.
• YouTube and Vimeo: we download a video’s still frame once at publish time and serve it from your site, for the same reason.

Third parties that collect data themselves

These only come into play when a Customer switches them on, and when they do, they collect data directly and under their own privacy policy rather than ours:

• Google Calendar, Planning Center, and YouTube, when a Customer connects the account. A Planning Center form placed on a page sends the visitor’s answers to Planning Center, who then hold that submission.
• Planning Center’s Church Center, if a Customer uses their pop-up form. That option loads Planning Center’s own script into the visitor’s browser and opens their window, so Planning Center sees that visitor directly. It is the one feature we offer that runs another company’s code on a published page, and it runs only if the Customer chooses it.
• Anything the Customer adds themselves. A Customer can put their own analytics, tracking scripts, or third-party embeds into their site settings. We do not review that code, we receive nothing from it, and what it collects is between the Customer, that provider, and the visitor. If a church site you are visiting loads a tracker, this is how.

We do not sell personal information to anyone in any of these groups, and we do not give any of them data for their own advertising. Each sub-processor is bound by their own privacy commitments, and we will publish material changes to the first list in advance.

We use a small number of first-party cookies and local-storage entries:

• A signed session cookie that proves you’re authenticated to the owner portal, page editor, and admin console.
• Firebase’s authentication cookies for the same purpose.
• Editor-only preferences (grid, rulers, sidebars, view mode) used to restore the editor the way you left it. These are stored against your account on our servers rather than in your browser, so they follow you between browsers and survive clearing your cache.
• On a published church site, one sessionStorage flag recording that a visit has begun in this browser tab. It holds no identifier, is not a cookie, is not sent anywhere, and is discarded when the tab closes. See § 3.
• Caching headers on published site responses for performance, not tracking.

We do not use third-party advertising cookies or cross-site trackers. Tenant churches may add their own analytics or embeds in their site settings; if they do, those tools collect data under the tenant’s own privacy policy.

A published tenant site can accept two kinds of submission from a visitor who is not signed in: a form submission and a prayer request. Both are rate-limited per visitor and carry a hidden anti-spam field. The church is identified from the hostname of the site being used, so a submission cannot be aimed at a church it did not come from.

A prayer request may include the request text, a display name, and optionally an email address or phone number. The owner moderates requests in the portal and chooses whether a request appears on the church’s public prayer wall.

When a request is published to a public wall, only the request text and the display name are included. An email address or phone number attached to a request is kept for the church’s prayer team, and for the update described below, and is never written into the published page. Requests marked private or limited to a group are never published.

The public wall is baked into the site at publish time rather than fetched live, so a newly approved request appears the next time the church publishes.

If you left an email address, we may use it to tell you what happened. When the church marks your request as prayed for or as answered, we send you one email saying so, quoting a short excerpt of your request. We send it once per request per outcome. We do not use the address for anything else: no newsletters, no marketing, and we do not pass it to any third party. Reply to the message if you would rather not be updated again, or leave the email field blank when you submit.

The prayer board lets the church owner invite trusted viewers (a “prayer team”) to read the church’s prayer requests without creating a Firebase account. Each invited viewer receives an email with a unique magic-link URL.

Server-side we store the invitee’s name, email address, a one-way hashed copy of the token, and a time-to-live so the token expires automatically after 180 days. Opening the landing page verifies the token and renders the prayer wall server-side: no cookie, no portal access, no ability to write. Owners can revoke a viewer at any time from the owner portal, which invalidates the token immediately.

The platform optionally connects to a small set of external apps. Each integration runs only when the Customer explicitly enables it, and only the documented scopes are requested:

• Google Calendar: read and write access to chosen calendars so events appear on the tenant site and in the owner portal, and so portal edits sync back.
• Planning Center: form embeds on the tenant site, plus optional person-push to Planning Center People when a form is submitted. We request the People scope only. We do not ask for access to Groups, Services, Registrations, or Calendar, and we cannot read them.
• YouTube: read-only access to the public video metadata on the Customer’s own channel, so they can pick a sermon to place on a page. We cannot upload, edit, or delete anything on the channel.

You can disconnect any integration at any time from the owner portal. Disconnecting revokes the stored refresh token and stops the data flow; previously synced records that already live in your tenant data remain until you delete them.

A small number of Citizen Sites employees can access customer accounts through an internal admin console in order to provide support, investigate a defect, or act on a Customer’s request. This includes the ability to sign in to the owner portal as a Customer (“impersonation”) so we can see what the Customer sees.

Employee access is restricted to a maintained list of staff identities, is separate from the Customer’s own credentials, and never exposes the Customer’s password. We use it only for the purposes above.

We retain personal information for as long as a tenant church’s account is active.

Missed payments. If a subscription payment fails, the church stays live for a seven-day grace period while Stripe retries, and we email warnings during that window. After the grace period the public site is suspended. Suspension is not deletion: the church’s data remains and the site comes back when billing is resolved.

Deleting a whole church. When a Customer asks us to delete their church, we delete the church record and its subcollections, its designs and their publish history, its domain mappings, its prayer-team tokens, its subscription record, its analytics tallies, and its uploaded media and font files from storage. The published site comes down with it. Deletion is permanent and we do not keep a restorable copy, so export anything you want to keep first.

Deleting one person’s information, on request. Anyone may ask for their personal information to be deleted, whether or not the law where they live grants them that right. Here is how it works in practice, because who holds the data decides who can act on it:

• If a church holds it (you submitted a form, sent a prayer request, or were invited to a prayer team), that church decides what happens to it and you should ask them first. We act on their instructions for that data. If they will not act on a valid request, contact us and we will help, and where we are able to we will delete the record ourselves.
• If we hold it as an account holder’s information, ask us directly and we will delete it.
• If it is already published on a church’s public site, removing it from our systems does not remove it from search-engine caches or third-party archives. We will take it off the site; we cannot reach into someone else’s index.

How we handle a request. We confirm we are talking to the right person, normally by confirming control of the email address on file, and we do not charge for a request. We respond within the time the applicable law allows and in any event without undue delay: for a U.S. state privacy request that is within 45 days, extendable once by a further 45 days where the law permits and we tell you why; under the GDPR and UK GDPR it is one month, extendable by two further months for a complex request. An authorized agent may act for you where the law allows, and we may ask that agent for proof of authority. If we refuse a request we will say why, and you may appeal by replying to our decision.

The narrow things we may keep after a deletion. We may retain what a law obliges us to keep, principally billing and tax records of payments actually made, and we may retain what we need to defend a legal claim, prevent fraud, or complete a transaction already in progress. Security and rate-limiting logs expire on the schedule below rather than being searched for one visitor’s records, since they are not organized by person and contain no account of who anyone is. Backups held by our infrastructure providers roll off on their own cycle. Nothing we keep under this paragraph is used for any other purpose.

The published files are not versioned; the design behind them is. Each publish replaces the last set of compiled files, and there is no rollback of a live site. What we do keep is a copy of the design each successful publish was built from: the most recent 25 per design, restorable by the owner from the editor, deleted automatically as newer ones are saved, and deleted outright with the design. This is a convenience, not a backup service.

Site analytics. The per-day visit tallies described in § 3 are kept for as long as the church’s account is active and are deleted with the church. They contain no personal information, so there is nothing in them to identify or remove on an individual’s request.

Short-lived records self-expire automatically: pending signups (1 hour), password-reset tokens (10 minutes), compiled previews (10 minutes), Stripe checkout fulfillment rows (2 days), Stripe webhook de-duplication records (14 days), self-service deletion requests (14 days), email and publish job de-duplication records (12 hours), Planning Center job de-duplication records (30 days), rate-limit buckets (1 hour), in-app notifications (30 days), portal-managed calendar events (2 years), and prayer-team magic-link tokens (180 days).

Tenants can request a full export or deletion at any time through our contact form. Individual End Users should contact their church first; if the church will not act on a valid request, reach out to us and we’ll help.

We use Firebase Authentication, Firestore security rules, per-tenant access checks at the API layer (with the owner’s JWT custom claim as the authoritative signal), signed session cookies, content security policy headers, HTTPS everywhere, IP-based rate limiting on every API endpoint, tighter rate limits and anti-spam checks on the endpoints open to anonymous visitors, server-side HTML sanitization, and least-privilege service accounts. We log security events and monitor for abnormal access patterns.

If something goes wrong. If we become aware of a breach of security leading to the unauthorized access, disclosure, or loss of personal information we hold for a Customer, we will notify that Customer without undue delay, describe what we know, and cooperate reasonably so the Customer can meet any notification duty it owes its own members. Where the law requires us to notify individuals or a regulator directly, we will.

No system is perfect. If you discover a security issue, please report it through our contact form. We will not pursue legal action against good-faith researchers who follow standard responsible-disclosure norms.

Citizen Sites is a business tool for adults. It is software for building and running a church’s website, and it is directed to the adults who do that work, not to children. We do not design it for children, market it to children, or treat children as an audience for it.

To create or administer a church account you must be at least 18 years old. We do not knowingly collect personal information from children under 13 through our marketing site or the signed-in portal, and we have no interest in doing so.

The websites churches build with it are a different matter. A published church website is a public website that anyone can read, and we place no age restriction on visiting one. Nothing here is meant to keep young people off a church’s site. It simply means the account, the editor, and the portal are tools for adults running the organization.

A note for churches. Church websites often touch children’s ministry. If a Customer builds a form that collects personal information from children under 13, for example a childcare, VBS, camp, or youth registration, the Customer is responsible for complying with the Children’s Online Privacy Protection Act (COPPA) and any similar law, including giving notice to parents and obtaining verifiable parental consent before collecting the information. We provide the form tool; the Customer decides what to ask for and is the party responsible for that decision.

If you believe a child under 13 has given us personal information without parental consent, contact us through our contact form and we will delete it promptly. If the information sits in a Customer’s tenant data, we will also notify that Customer.

Depending on where you live, you may have rights to access, correct, export, or delete your personal information, to object to or limit processing, or to lodge a complaint with a supervisory authority.

Who to ask. For information a church holds about you as one of its members, form submitters, or prayer-request submitters, that church is the controller and you should contact the church first. We act on the church’s instructions for that data. If the church will not act on a valid request, reach out to us through our contact form and we’ll help. For information we hold about you as a Citizen Sites account holder, contact us directly.

We will verify a request before acting on it, usually by confirming control of the email address on file. We respond within the time the applicable law allows, and we will not discriminate against you for exercising a privacy right. You may use an authorized agent where the law permits, and we may ask the agent for proof of authority.

For Customers. If your church needs a data processing agreement or similar written terms to satisfy its own obligations, ask us through our contact form and we will put one in place.

Residents of California and of other states with comprehensive privacy laws, including Colorado, Connecticut, Texas, Utah, and Virginia, may have specific rights over their personal information. Depending on the state, those rights can include the right to know what we collect and why, to access a copy, to correct inaccuracies, to delete, to opt out of sale, sharing, or targeted advertising, to limit the use of sensitive personal information, and to appeal a decision we make on a request.

We do not sell or share personal information as those terms are defined under the California Consumer Privacy Act as amended by the California Privacy Rights Act, and we do not process personal information for targeted advertising or cross-context behavioral advertising. We do not use or disclose sensitive personal information for any purpose beyond what is described in this policy. We have not sold or shared personal information in the preceding twelve months, and we do not knowingly sell or share the personal information of anyone under 16.

The categories of personal information we collect, the sources, the business purposes, and the categories of recipients are described in § 3, § 4, § 5, and § 6. Retention is described in § 12.

To exercise a right, use our contact form. If we deny a request, you may appeal by replying to our decision; we will respond to an appeal within the period your state’s law provides and tell you how to contact your attorney general if you disagree with the outcome.

Do Not Track and Global Privacy Control. Because we do not track users across third-party sites and do not sell or share personal information, we do not change our behavior in response to a Do Not Track browser signal. We honor a Global Privacy Control signal where applicable law requires it.

Citizen Sites is operated from the United States. By using the platform from outside the U.S., you understand that your information will be processed in the U.S. and other countries where our service providers operate.

Today there is no AI in this product. Nothing you write, upload, or collect through Citizen Sites is sent to an AI model, and no part of the platform generates text, images, or decisions with one. We say this plainly because it is a fair question to ask of any software in 2026, and because a vague answer would not be an answer.

We do not train models on your data, and that will not change. We do not use Customer Content, form submissions, prayer requests, or anything else we hold for a church to train, fine-tune, or evaluate an AI model, whether ours or anyone else’s, and we do not permit our service providers to do so with data they process for us. This commitment is not conditional on the paragraph below.

If we ever add an AI feature, here is what we are promising now. We may build one, and if we do: we will describe in this policy what it does, which provider processes the data, and what that provider may keep, at least 30 days before it turns on; it will be off until a Customer switches it on, never applied to existing data by default; it will not touch prayer requests or form submissions unless the Customer specifically directs it to; and it will still be covered by the no-training commitment above. A feature that cannot meet those conditions is one we will not ship.

You may use your own AI tools, and then it is on you. Nothing here stops a church from drafting its pages with ChatGPT, generating an image, or pasting anything else it likes into the editor. That is your content and we treat it exactly like content you typed. But once you put information into a tool of your own choosing, that tool’s provider has it under their terms, not ours, and we have no visibility into what they do with it. Two cautions worth stating: do not paste a member’s personal information, a form submission, or a prayer request into an outside AI tool without that person’s knowledge, and check what an AI writes before you publish it, because you are responsible for what appears on your site either way.

We’ll update the “Last updated” date at the top whenever this policy changes. For material changes (new sub-processors, expanded data uses, new categories of collection) we’ll notify Customers by email at least 30 days before the change takes effect.

For privacy questions, requests to access or delete information, or anything else covered by this policy, write to us at info@buildcitizensites.com or through our contact form. Either reaches us. We read every message ourselves, and the email address is the one to use if you would rather not depend on a web form.

The data controller, and the party accountable for this policy, is Citizen Sites LLC, a United States limited liability company.