BishOps Privacy Policy

1. Who We Are and How to Reach Us

BishOps is a ward operations platform for LDS bishoprics and ward leadership teams. It is operated by:

BishOps Software, LLC
Incorporated in the Commonwealth of Virginia (Entity ID: 11996917)
Email: privacy@bishops.app

Geographic service restrictions: BishOps is not currently available to wards located in the European Economic Area, United Kingdom, Brazil, South Korea, China, Russia, or Turkey. Ward creation is blocked for wards in these regions at the point of setup. These restrictions are in place pending appointment of legally required local data protection representatives and, where applicable, resolution of data localization requirements under applicable national law. Ward leaders in restricted regions who would like to be notified when BishOps becomes available in their area may contact privacy@bishops.app.

For the purpose of GDPR, BishOps acts as a data processor on behalf of each ward (the data controller), except where described otherwise in this policy.

2. Who This Policy Is For

This policy covers information BishOps processes in the course of providing the platform to:

• Ward and branch leadership teams (bishops, counselors, clerks, executive secretaries, music leaders)
• Individual members whose data is entered by those leaders
• Visitors to public ward bulletins

3. What Data We Collect and How It Enters the System

3.1 Member data entered by ward leaders

Ward leaders enter and manage the following data about members of their ward:

• Name
• Birth year and birth month (used to determine age category for interview routing, youth tracking, and time-of-year scheduling; BishOps receives the full date of birth from leaders during entry or file import, but retains only the birth year and birth month — the day is discarded immediately upon processing and is not stored. The birth month enables two specific operational purposes: surfacing baptism interviews for children approaching age 8, and distributing annual youth interviews across the calendar year rather than batching them. The day of birth is discarded because it is the high-value identity credential; retaining only month and year prevents BishOps from being a viable re-identification vector if combined with external data.)
• Temple recommend type and expiration date (see Section 4)
• Current calling and sustained date
• Free-text notes in the calling pipeline and interview modules
• Covenant Path tracking (optional, visible to the bishopric, the Elders Quorum and Relief Society presidencies, and other ward council leaders who are given access): which milestone a leader is helping a member prepare for (preparing for baptism, temple baptisms, priesthood ordination, the endowment, sealing, or returning to activity), a chronological log of shared notes, and any tasks leaders create from a note (visible only to the same leaders who can see the visit and contact log, below, and to the leader the task is assigned to; tasks created from Covenant Path before October 2026 remain visible to ward council members, as they were when created). A leader may also type a name for someone who is not on the ward roster, and BishOps then stores only the name the leader typed. The bishopric can also keep private notes on an entry that only the bishopric office can read; they are never shown to other leaders. This is a leaders' planning list, not an ordinance record: BishOps does not receive or store ordinance completion dates or any data from Church records systems.
• Visit and contact log (visible to the bishopric, the Elders Quorum and Relief Society presidencies, the ward mission leader, and the other covenant-path leaders above): notes about visits to and contact attempts with ward members. Each entry holds the date, the method (visit, call, text, message or other), the outcome (reached, not home, left a message, declined or other), free-text notes, the type of visit (covenant path, Elders Quorum or Relief Society visit, missionary or other), and which leader wrote it. Leaders use it to coordinate who is visiting whom. A leader can also set a contact status on a member: Do not contact (the member asked not to be contacted), Reported moved (believed to have moved) or Couldn't locate (visited, and no one knows them), with an optional short note, who set it and when. The status is visible only to the leaders who can see this log, so that visits are not duplicated and a member's wishes are respected. Any of these leaders can set a status and can change or clear Reported moved and Couldn't locate; only the bishopric can clear or change Do not contact. Setting, changing or clearing a status adds an entry to the member's log (merging two member records and deleting a member do not), and Reported moved also creates a task for the bishopric's ward clerk, visible to the bishopric, to confirm the move in the Church's own records; a status never marks a member as moved out. A leader can also create a task from a note; that task is visible only to the same leaders who can see this log and to the leader it is assigned to. It covers ward members, plus the notes on a Covenant Path entry that a leader recorded by name (see the Covenant Path bullet above). People who are being taught by the missionaries are tracked in the Church's own tools, not in BishOps. Notes linked to a bishopric-only private Covenant Path entry are visible only to the bishopric office. Entries are shown to the leaders above, never on the public bulletin. Section 6 describes how long they are kept.
• Speaking and prayer preferences and general notes (optional, visible only to the bishopric, the ward clerk and the executive secretary): a leader can record that a member prefers not to be asked to speak, or prefers not to be asked to pray, with an optional short note, and add general notes about the member. BishOps stores when each preference was recorded and by which leader, and when the general notes were last changed and by which leader, but keeps no history of earlier versions. If that leader's account is later removed, the name is dropped and the preference or note stays. Members with a recorded preference are shown last, marked, in the lists leaders use to choose speakers and people to pray, and can still be chosen. Other leaders, including the music coordinator, organization presidencies and the ward mission leader, cannot see them, and they are never shown on the public bulletin. Section 6 describes how long they are kept.

BishOps does not collect member addresses, phone numbers, or email addresses from a ward's roster or directory, and does not ask leaders to enter them when adding or importing members. BishOps also does not collect financial records, official Church ordinance records, or membership council records. The Covenant Path tracker above records only what a leader chooses to enter to plan and follow up; it does not hold ordinance dates and is not a substitute for Church records, although the milestones and notes it does hold can still reveal religious practice (Section 4). Section 3.14 describes the separate, narrower case where a person chooses to type their own email address or phone number into a public request or appointment form.

3.2 How member data enters BishOps

Member data enters BishOps through two paths:

1. Manual entry — leaders type data directly into the application
2. File import — LCR displays member data in an on-screen table. Leaders copy that data from the LCR interface into a local spreadsheet (CSV or Excel), then upload that file to BishOps. BishOps parses the file and stores the fields listed above. BishOps does not access LCR directly, via API, or through any automated means.

3.3 Sacrament meeting and program data

BishOps stores sacrament meeting planning data, including meeting dates, names of assigned speakers, prayers, and conductors, hymn selections, ward business items, and meeting notes. When a ward publishes a bulletin, some of this data becomes publicly accessible. See Section 7.

3.4 Leadership account data

When a leader creates a BishOps account, we collect their email address, name (as provided), and role assignment within the ward. We use Supabase Auth for authentication. Leaders sign in via email/password, magic link, or "Sign in with Google." When a leader chooses Google sign-in, we receive only their Google account's email address and basic profile name from Google's sign-in scopes, and use them solely to create and identify their BishOps account. Google sign-in grants BishOps no access to the leader's Gmail, Drive, Photos, or calendar; the separate, optional calendar connection described in Section 3.8 is the only feature that reads or writes Google user data.

3.5 Technical and usage data

BishOps is hosted on Vercel. Vercel collects standard hosting metrics (request counts, error rates, page response times) as part of normal infrastructure operation. These metrics do not include member names or other member-identifying data. We also use Sentry, an error-monitoring service, to find and fix defects (Section 9). When the application hits an error, Sentry receives a technical error report (the type of error, its message and stack trace, the page path, and the browser and device type) and, only when an error occurs, a masked session replay of the moments around it in which all text and form inputs are hidden and no request or response contents are recorded. Sentry also receives timing data for a sample of about one in ten page loads and requests (page paths and how long they took). BishOps configures Sentry to strip URL query strings, request bodies, cookies, and headers from error reports and timing data, to shorten error messages, and not to attach user identities, so that member data is not sent; an error message could still contain a fragment of text the application was handling when it failed. Sentry may see the IP address of the device sending a report and keeps reports for up to 90 days. We do not use third-party product analytics or behavioral tracking beyond what Vercel provides as a hosting service and what Sentry receives for error monitoring.

BishOps does keep two kinds of first-party usage measurements of its own. Neither is shared with any third party, neither involves member records, and both are visible only to the platform operator.

Sign-up funnel. When someone visits the "Get started" page, or a signed-in leader without a ward opens the page for creating one, BishOps records which steps of the sign-up process they reach (for example, "searched for a ward", "selected a ward", "hit a validation error", "created an account") under a random identifier that exists only in that browser tab and is discarded when the tab closes. If the sign-up completes and an account is created, BishOps records which ward that sign-up produced and sets a cookie (bo_fid) holding the same random identifier for up to 90 days, so that later steps such as email verification and first setup can be linked to the same sign-up. This means that, once an account exists, BishOps can see that a particular sign-up led to a particular ward; the identifier is still never stored with a name, email address, or IP address. A visitor who does not complete sign-up, including a visitor in a region where BishOps is not available, never receives a cookie; the steps they reached are recorded only under the temporary tab identifier, which is not tied to them in any way and is discarded with the tab. Validation errors are recorded as a code (such as "password too short"), never as the text the visitor typed.

Feature usage by leaders. For signed-in leaders, BishOps counts how many times each area of the application (for example, the interviews page or the sacrament meeting planner) is opened each day, grouped by ward and by role (for example, bishopric or ward clerk). The daily count per ward, role, and area is stored, and page addresses are reduced to a general pattern before counting, so no record identifiers, member names, or other specific content are stored. To count how many different leaders use each area each week, BishOps also keeps a scrambled code for each signed-in leader in each area for the current week. Each code is made from the leader's account, the ward, and the area together with a secret key that changes every week, so a leader's codes in different areas cannot be matched to one another, and no code is ever stored with a name or email address. After the week ends, a daily cleanup reduces the codes to one count per ward and area and then deletes both the codes and the key, after which they cannot be linked to any person. No record of which areas an individual leader opened is kept beyond about eight days (deleted records remain in automated backups for up to about 7 more days; see Section 6). In a small ward where one person holds a role, a role's daily or weekly counts may in practice reflect that person's use of the application. These counts are used only to understand which features are used and to improve the platform; they are never used for advertising, never shared, and never shown to other wards.

3.6 Help agent interactions and feature requests

BishOps includes an in-app AI help assistant. When a leader uses the help assistant, the text of their messages is sent to Google Gemini to generate a response (see Section 8.2). No ward data, member records, or other ward-specific information is included in these requests. Conversation history exists only in the browser for the duration of the session and is not stored on BishOps servers.

When a leader submits a feature request through the help assistant, BishOps stores the request text and the ward's identifier. This information is used solely to track and prioritize product improvements.

3.7 Transactional emails to leaders

BishOps sends transactional emails to leaders about ward activity, including task assignments, interview assignments, and interview bookings made by members through public booking links. These emails may contain a member's name and interview type. Emails are delivered through Resend (see Section 9) and are never used for marketing. Leaders may adjust or disable these notifications in their account preferences.

3.8 Google Calendar connection (optional, leaders only)

Leaders who hold interviews may optionally connect their personal Google Calendar to BishOps. This feature is off unless a leader explicitly connects through Google's consent screen, and it never involves member accounts — members have no BishOps accounts and are never asked to connect anything.

When a leader connects their Google Calendar, we collect and process:

• OAuth tokens granted by Google, which we store encrypted (AES-256-GCM) and use solely to make the calendar requests described below. The tokens are never readable through the application interface, including by the leader who owns them.
• The Google account's email address, shown to the leader on their own account page so they can see which account is connected. It is not used for matching, communication, or any other purpose.
• Free/busy intervals from the leader's calendar — start and end times only. Google's free/busy interface does not transmit event titles, descriptions, locations, or attendees to us, so that information never enters BishOps. Intervals are held in a short-lived cache and used for one purpose: hiding interview time slots that conflict with the leader's existing commitments.

In the other direction, when an interview is booked in BishOps we create a mirror event on the leader's connected calendar. By default that event contains no member data: a generic localized title ("Interview (BishOps)"), the meeting link for video interviews, and a link back to the app. A leader may choose, on their own account page, to include the interviewee's name in the event title and the interview type and age group (youth or child) in its description — for example so an executive secretary who views the leader's shared calendar can arrange a second adult for a youth interview. That choice is off unless the leader turns it on, applies only to that leader's connected calendar, and is visible to anyone the leader has shared that Google calendar with. The event content lives on the leader's Google Calendar, not on BishOps systems: switching the option off rewrites the leader's upcoming events without those details, but events for interviews that have already taken place stay as they were written unless the leader deletes them in Google. Interview notes never appear on the external calendar in either mode, and members are never added as event attendees.

A side effect leaders should understand: anyone holding a valid booking link for a leader can observe which time slots are unavailable, and with the calendar connected those unavailable slots now reflect the leader's personal calendar as well as ward bookings. Only availability patterns are observable — never event details.

Leaders may disconnect at any time from their account page, which revokes BishOps' access with Google and deletes the stored tokens, or revoke access directly from their Google account settings.

Calendar subscription link (optional, separate from the Google connection). A leader may create a private calendar subscription link for their own scheduled interviews and tasks, to add to Apple Calendar, Outlook, Google Calendar, or another calendar app. By default the feed shows only generic titles ("Interview (BishOps)" and "Task (BishOps)") with no member names and no interview types. A leader may turn on member names for their own link, in which case anyone who has the link can see the interviewee's name and interview type and the text of the leader's tasks. The link works without signing in, so it should be kept private. The feed also includes ward meeting times and, if enabled, public Church-calendar events. A leader can regenerate the link, which stops the old one working, or revoke it, at any time from their account settings. This feed is separate from the youth activities feeds in Section 3.11. When someone adds the feed to Google Calendar, Google fetches the link on their behalf under Google's own privacy policy; BishOps receives nothing from Google in return.

Limited Use disclosure: BishOps' use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Google user data is used only to provide the calendar features described above, is never sold, is never used for advertising, and is never transferred to third parties except as necessary to provide these features (our hosting and database processors, Section 9) or as required by law.

Google user data and AI/ML: Google user data — raw, aggregated, or derived — is never sent to any artificial intelligence or machine learning model, and is never used to develop, train, or improve any generalized or foundational AI/ML model, whether our own or a third party's. The AI features described in Section 8 operate only on the inputs described there and have no access to data received from Google APIs.

3.9 Embedded tutorial videos (leaders only)

Signed-in ward leaders may watch short tutorial videos on the in-app Videos page and from "Watch a walkthrough" links on related pages. Video thumbnails are served from BishOps' own servers, so simply viewing the page sends nothing to any third party. The YouTube video player loads only when a leader clicks to play a video. When it loads, the leader's browser connects directly to YouTube (a Google service) using YouTube's privacy-enhanced mode (youtube-nocookie.com), which does not set YouTube's standard tracking cookie; YouTube receives the leader's IP address and may store a small local identifier in the browser to remember playback settings. No ward data, member data, or BishOps account information is sent to YouTube or Google as part of this feature. Because the leader's browser communicates with YouTube directly, that interaction is governed by YouTube's Privacy Policy, not by a BishOps data processing agreement.

3.10 Inactivity outreach and feedback survey (ward creators only)

If a ward has gone without any recorded activity for an extended period, BishOps may send the leader who set up the ward up to two personal, founder-voiced emails: a check-in after about two weeks of inactivity, and, if the ward remains inactive, an invitation after about four weeks to a short survey asking why the ward stopped using BishOps. Both emails honor the recipient's notification preferences and can be turned off from the account page, the same as the other product emails described in this policy.

The survey is reached through a unique link in the email and does not require signing in. It asks the recipient to choose a reason from a short list (for example, lack of time, missing features, or difficulty getting buy-in from the rest of the bishopric) and, optionally, to add up to three brief written answers: more detail on the reason, what could have been better, and what would bring them back. The survey also asks whether BishOps may follow up by email; saying yes is optional, and it is the only thing that connects a response to the recipient's email address for follow-up.

Survey responses are seen only by authorized BishOps personnel, on an internal reporting page, and are used solely to understand why wards stop using the platform and to improve it. They are never shared with any third party, never used for advertising, and never shown to other wards. A response is retained until the ward account is deleted, at which point it is deleted with the rest of the ward's data; there is currently no automatic deletion before then.

3.11 Public youth activities page and calendar feeds (optional, leaders only)

Leaders who plan youth activities may optionally publish a read-only web page of the ward's planned youth activities at an unguessable link, and calendar feeds that families can add to Apple Calendar, Outlook, or Google Calendar — one feed for all youth and one for each quorum and class. The page and feeds are off unless a leader turns them on, are not listed or linked anywhere on the internet, use the same noindex/nofollow protections as the public bulletin (Section 7) so search engines do not index them, and are only reachable by someone who has been given the link. A leader can turn the page off, or replace any link so the old one stops working, at any time from the youth activities page.

The page and feeds carry each activity's title, date, start and end time, location, description, and the names of the quorums or classes it is for, plus "No Youth Activities" notices. Feeds also include the past 60 days of activities so a family's calendar app does not lose recent history when it refreshes. Nothing from the member records described in Section 3.1 is included, and no BishOps account is needed to view them. BishOps does not know who opens the page or adds a feed, and never receives a family's email address or calendar contents. When someone adds a feed to Google Calendar, Google fetches the feed link on their behalf under Google's own privacy policy; BishOps sends nothing to Google itself.

The title, description, and location are free text typed by leaders, and because anyone holding a link can read them, the application reminds leaders at the point of entry to keep member names and sensitive details out of them.

3.12 Event flyers (optional, leaders only)

Leaders planning a ward or youth activity may optionally attach a flyer to the event — an uploaded image, an uploaded PDF, or a link to a page hosted elsewhere. Uploading is off unless a leader chooses to attach a file or link to a specific event. At the point of upload, the leader confirms that the flyer has no photos of youth or children, no personal phone numbers, and no home addresses; a flyer that would show any of those is expected to be linked to instead of uploaded, or cropped before uploading.

Uploaded flyer files are stored in a dedicated public storage bucket on our database processor, Supabase (Section 9), at an unguessable, randomly generated address. A flyer is not listed or indexed anywhere; it is reachable only by someone who has the specific link. That link appears, labeled "View flyer," everywhere the event itself is shown to families or the public: the public youth activities page and its calendar feeds (Section 3.11), and — when a ward or youth event with a flyer is published as a bulletin announcement — the public bulletin (Section 7). The flyer is always a link that opens in a new tab; it is never shown as an inline image on any public page. A flyer's file or link is never sent to Google Gemini or any other AI model. A flyer is deleted automatically 30 days after its event's start date, or immediately if the leader removes or replaces it.

3.13 Full ward data export (admins only)

Ward leaders with admin-level access may generate a complete, downloadable export of their own ward's data as a ZIP file. The export contains one file per type of ward-operational record the ward has entered — including members (name, birth year and month, temple recommend type and expiration date, calling history, and free-text notes; see Section 4 for the significance of temple recommend data), interviews, calling pipeline records, Covenant Path entries, the shared Covenant Path notes, the bishopric's private Covenant Path notes, the visit and contact log, meetings, sacrament and music planning, tasks (including tasks created from notes and their assignees), announcements, events, and similar ward content — plus a members.csv file for spreadsheet use. The export never includes another ward's data, and it excludes live credentials (such as OAuth tokens or booking-link tokens), internal system logs, and BishOps' own aggregate analytics, none of which is ward content. BishOps does not retain a copy of the file after it is generated; once downloaded, safeguarding it — because it may contain temple recommend data, notes about members, and other sensitive member data — is the admin's responsibility.

3.14 Contact details you choose to provide

BishOps does not collect phone numbers or email addresses from a ward's member roster or directory (Section 3.1). Two kinds of public form, both reachable from a ward's bulletin, instead let a person type their own contact details directly, so a ward leader can follow up with them about that one thing:

• Requesting an interview (/request/[token]) — a person requesting a bishop interview, temple recommend interview, calling-related conversation, or other appointment provides their name and at least one of an email address or phone number, so a leader has some way to respond. This is required by the form, not optional, because a request with no way to reach the person back is not actionable.
• Booking a specific appointment time — through a ward's shared tithing-declaration sign-up link (/signup/[token]) or a leader's individual appointment link (/book/[token]), a person may optionally provide an email address (and, on the shared sign-up link, a phone number) so BishOps can send a confirmation and a reminder shortly before the appointment, and so the leader can reach them if plans change. Leaving these fields blank does not prevent booking.

In both cases, the information is used only to handle that specific request or appointment — never to build a mailing or calling list, never matched against the member roster, and never sent to any third party except Resend (Section 9), which delivers the confirmation/reminder email on BishOps' behalf when an email address is given. A phone number is never sent to Resend or any other processor; it is visible only to the ward leaders below for their own follow-up.

This information is visible only to the ward's bishopric, ward clerk, and executive secretary — the roles that handle interview scheduling. It is not visible to other roles, including the music role.

Retention: contact details submitted through the request form are cleared automatically 90 days after the request is closed or converted to a scheduled interview, and are cleared immediately, without waiting for that window, if the request is linked to a member whose record is later erased (Section 11). Contact details submitted through a booking or sign-up link are cleared automatically once that appointment is marked completed or declined. See Section 6.

3.15 Phone notifications (optional, leaders only)

A leader may turn on notifications for their own phone or computer from their account settings. Nothing is sent to a device until that leader turns it on there, and they choose which kinds they get: interview reminders, new interview requests, newly scheduled or rescheduled interviews, a reminder when Sunday's program has not been published, and reminders before leadership meetings.

Turning notifications on stores, for that leader's account only, the delivery address their browser creates for the device (a web push endpoint), the encryption keys that go with it, the browser's identification string, which names the browser, its version and the operating system (so the leader can tell their devices apart), and when a notification was last delivered. It also stores the leader's notification choices and a record of which reminders were already sent (the kind of reminder, which interview or meeting it was for, and when), so the same reminder is never sent twice.

A notification contains only a short title and, for reminders, a time, such as "Interview at 7:30 PM" or "New interview request," plus a link into BishOps. It never contains a member's name, an interview type, a reason for a request, or any meeting content. Each notification is delivered through the push service run by the leader's browser maker (for example Google for Chrome and Android, or Apple for Safari and iPhone), which BishOps does not choose. Notifications are end-to-end encrypted with the device's own keys, so the push service can route them but cannot read them.

A leader can turn notifications off at any time from the same settings page, which deletes that device's delivery address and keys immediately. A delivery address the push service reports as no longer valid is deleted automatically. The record of which reminders were already sent is deleted after 30 days. Everything else described here is deleted when the leader's account is deleted.

3.16 Founding Wards requests and setup calls

Before anyone has a BishOps account, a person can ask to join the Founding Wards program through the form at /founding. The form collects their name, email address, ward and stake, the message they write, an optional name of the person who introduced them, and the language the form was shown in. We use this only to review the request and to contact the person about it.

If they book a setup call, BishOps stores the scheduling details (the time, the booking status, and the language and time zone used to show them their emails). BishOps creates an event, with a Google Meet link, on the founder's own Google Calendar showing the person's name and ward, and emails a confirmation through Resend (Section 9). The person's email address is not added to that event as a guest.

This information is not part of any ward's data, is not visible to ward leaders, and is visible only to BishOps' platform administrator.

Retention: it is deleted automatically 90 days after the last activity on the request, meaning the latest of the request itself, a setup call being booked, held or cancelled, and the last email sent about it. A request with a setup call still scheduled is never deleted. If the request was approved and the ward received the Founding Ward program, BishOps keeps that request as its record of the grant, and the 90-day deletion does not apply to it. See Section 6.

4. Temple Recommend and Related Data — Special Category Information

Temple recommend type and expiration date reveal religious belief and practice. Under GDPR Article 9, this is special category personal data.

The same can be true of Covenant Path milestones (for example, that a leader is helping a member prepare for baptism, the endowment or a sealing, or return to activity) and of visit and contact notes: the milestone a leader records, and the fact that a member is being visited or contacted by ward leaders, can reveal religious belief or practice. Free-text notes can also record other personal circumstances that a leader chooses to type, such as health, family or financial situation. BishOps does not ask leaders for that information, but it cannot prevent it from being typed. These notes and milestones are not ordinance records (Section 3.1), and they are treated as special category data for the purposes of this policy.

We process this data on the basis of Article 9(2)(d) GDPR — processing carried out in the course of legitimate activities by a religious organization, relating to members of that organization, with appropriate safeguards. This data is entered by authorized ward leaders, used solely for scheduling temple recommend renewal interviews and, for Covenant Path milestones and visit and contact notes, for coordinating ministering and follow-up among the leaders who have access (Section 3.1), accessible only to the ward's authorized leadership team, and not shared with any third party for any purpose other than the technical processing required to operate the platform. Interview type, which may indicate a temple recommend interview, appears in booking confirmation and assignment emails sent to the assigned leader via our email processor (Resend).

Under CPRA (California), temple recommend status, and Covenant Path milestones and visit and contact notes to the extent they reveal religious belief or practice, are also sensitive personal information. BishOps does not use or disclose this information for purposes beyond what is described in this policy. California residents have the right to direct BishOps to limit its use of sensitive personal information to what is necessary to perform the services described in this policy.

5. Why We Process Data (Legal Bases)

Processing activity	Legal basis
Storing and displaying member name, birth year and month, calling, and recommend data to authorized ward leaders	Legitimate interests (GDPR Art. 6(1)(f))
Processing temple recommend type and expiration date	Art. 9(2)(d) — religious organization processing members' data
Tracking Covenant Path milestones and the shared and bishopric private notes on them (Section 3.1)	Legitimate interests (Art. 6(1)(f)) — coordinating ministering and support among ward leaders; for the special-category aspect, Art. 9(2)(d) — processing by a religious body in the course of its legitimate activities, relating to its members, and not disclosed outside it
Keeping the visit and contact log of visits, contact attempts, notes and contact statuses about ward members (Section 3.1)	Legitimate interests (Art. 6(1)(f)) — coordinating ministering and support among ward leaders; for the special-category aspect, Art. 9(2)(d) — processing by a religious body in the course of its legitimate activities, relating to its members, and not disclosed outside it
Storing leader account credentials and authentication data	Contract (Art. 6(1)(b))
Publishing speaker and prayer names in the public bulletin	Legitimate interests (Art. 6(1)(f))
Processing leader message text through the AI help assistant	Legitimate interests (Art. 6(1)(f))
Storing feature requests	Legitimate interests (Art. 6(1)(f))
Processing a leader's Google Calendar connection (OAuth tokens, connected account email, free/busy intervals) and writing mirror events to their calendar (Section 3.8)	Consent (Art. 6(1)(a)) — the leader affirmatively opts in through Google's consent screen; withdrawable at any time by disconnecting from the account page or revoking access in their Google account settings
Publishing the ward's youth activities on a read-only page and calendar feeds reachable by link (Section 3.11)	Legitimate interests (Art. 6(1)(f)) — informing ward families of planned youth activities; the ward chooses to turn it on, and no member data is published
Processing data for platform administration and technical support	Legitimate interests (Art. 6(1)(f))
Receiving technical error reports and masked session replays in Sentry to find and fix defects (Section 3.5)	Legitimate interests (Art. 6(1)(f)) — keeping the platform working; configured so member data is not sent
Providing a leader's private calendar subscription link (Section 3.8)	Legitimate interests (Art. 6(1)(f)) — the leader chooses to create the link; it is generic by default, and member names appear only if the leader turns them on
Showing an event flyer to families and, when the event is announced, on the public bulletin (Section 3.12)	Legitimate interests (Art. 6(1)(f)) — the ward chooses to attach a flyer, and it carries no member data by design
Providing ward admins a complete export of their own ward's data (Section 3.13)	Legitimate interests (Art. 6(1)(f)); also supports the right to data portability described in Section 11
Recording sign-up funnel steps, daily feature-usage counts, and weekly counts of how many different leaders use each area (Section 3.5)	Legitimate interests (Art. 6(1)(f)) — measuring and improving the platform using first-party data that contains no member records; the short-lived weekly codes behind the leader counts are deleted within about eight days
Sending inactivity check-in emails and a feedback survey invitation to the leader who set up a ward, and processing the survey responses (Section 3.10)	Legitimate interests (Art. 6(1)(f)) — understanding and reducing account inactivity; where the recipient agrees to follow-up contact, that follow-up rests on consent (Art. 6(1)(a)), withdrawable at any time
Processing an email address or phone number a person chooses to type into a public interview-request or appointment-booking form, to respond to that request (Section 3.14)	Legitimate interests (Art. 6(1)(f)) — responding to a request the person initiated by providing their own contact details
Storing a leader's device delivery address and sending them the notifications they chose (Section 3.15)	Consent (Art. 6(1)(a)) — the leader turns notifications on for their own device; withdrawable at any time from their account settings
Processing the details a person submits through the Founding Wards request form, and the scheduling details of a setup call they book, to review the request, contact them and hold the call (Section 3.16)	Legitimate interests (Art. 6(1)(f)) — responding to a request the person initiated by providing their own contact details
Keeping a minimal billing record for 7 years after a ward that paid for BishOps deletes its account (Section 6)	Legitimate interests (Art. 6(1)(f)) — keeping the payment and subscription records needed to answer billing, refund and tax questions. The record contains no member data
Deleting a ward's paid-feature data 12 months after its paid plan ends (Section 6)	Legitimate interests (Art. 6(1)(f)) and the storage-limitation principle — not keeping data for features the ward no longer uses

6. Data Retention

Data type	Retention
Active member records	Retained while the ward account is active and the data serves an operational purpose
Interview and calling history	Retained for the life of the ward account
Sacrament meeting records	Retained for the life of the ward account
Free-text notes	Retained as part of the record to which they are attached; leaders may delete individual notes at any time
Leader account data	Retained while the account is active; deleted upon verified account deletion request
Google Calendar connection (OAuth tokens, connected account email)	Retained while the connection is active; deleted immediately when the leader disconnects (we also revoke our access with Google) or when the account is deleted
Google Calendar free/busy cache	Start/end intervals only; refreshed continuously and served from a cache measured in minutes, fully replaced on each refresh and deleted with the connection
Public youth activities page and feed links (Section 3.11)	The links exist while the page is turned on; replacing a link deletes the old one immediately, and all of them are deleted with the ward account. Copies a family's calendar app already fetched stay on that device
Calendar subscription link (Section 3.8)	The link exists until the leader regenerates or revokes it, which stops the old link working immediately, and is deleted with the leader's account. Copies a calendar app already fetched stay on that device
Event flyers (Section 3.12)	Deleted automatically 30 days after the event's start date, or immediately if a leader removes or replaces it
Published bulletin records	Automatically unpublished after a maximum of 3 weeks (ward-configurable)
Sign-up funnel events (Section 3.5)	Deleted automatically after 180 days; the bo_fid cookie expires after 90 days
Daily feature-usage counts by ward, role, and area (Section 3.5)	Deleted automatically after 13 months
Weekly scrambled codes for each leader and area (Section 3.5)	Deleted, together with that week's key, by the first daily cleanup after the week ends (at most about eight days after a leader's first visit that week)
Weekly counts of different leaders by ward and area (Section 3.5)	Deleted automatically after 13 months
Feedback survey responses (Section 3.10)	Retained until the ward account is deleted; no separate automatic deletion currently applies
Visit and contact log entries about a member (Section 3.1)	Kept for as long as the member remains in the ward; the age of an entry alone never deletes it for an active member. Deleted automatically 90 days after the member is marked as moved out, but only if the member is still marked as moved out when the deletion runs; a member who returns before then keeps their entries. Deleted immediately when the bishopric deletes the member's record (the Delete member action), which also deletes the tasks created from that member's notes; a deleted member cannot be restored. Restricting processing hides the member but keeps their entries until the restriction is lifted or the record is deleted. The leader who wrote an entry can delete it at any time while they still have access; a leader who has lost access can no longer delete their own entries, but the bishopric still can. Entries linked to a bishopric-only private Covenant Path entry are visible only to the bishopric office and are deleted with that entry. All entries are deleted when the ward account is deleted
Contact status of a member: Do not contact, Reported moved or Couldn't locate (Section 3.1)	Kept until a leader clears it (Do not contact can only be cleared by the bishopric). Reported moved and Couldn't locate are cleared automatically when the member is marked as moved out; Do not contact is kept, and is deleted automatically 90 days after the member is marked as moved out, but only if the member is still marked as moved out when the deletion runs. Deleted immediately when the bishopric deletes the member's record (the Delete member action), and with the ward account. The entries a change adds to the visit and contact log follow that log's retention above. The task created for Reported moved is a task and follows the task retention in this section; it is closed when the status is cleared or the member is marked as moved out, and deleted with the member's record
Speaking and prayer preferences and general notes (Section 3.1)	Kept until a leader changes or clears them. "Clear all notes" on a member removes the notes and the note on each preference but keeps the preferences themselves. Deleted immediately when the bishopric deletes the member's record (the Delete member action), and with the ward account. When two member records are merged, the preferences and notes move to the record that is kept: a preference set on either record is kept (the kept record's own note is used if both have one), and the general notes are joined, shortened to 2,000 characters if longer. Restricting processing of a member hides them but keeps these until the restriction is lifted or the record is deleted. Marking a member as moved out does not delete them.
Covenant Path entries, shared notes and bishopric private notes (Section 3.1)	Kept while the member remains in the ward and the ward account is active. A leader can archive an entry, and the bishopric can delete an entry together with its private notes at any time. Deleted immediately when the bishopric deletes the member's record (the Delete member action): the member's Covenant Path entries are removed together with their shared notes and any bishopric private notes, and the tasks that leaders created from that member's notes are deleted as well. All of them are deleted when the ward account is deleted. Shared notes now appear in the visit and contact log above and follow its rules
Tasks created from a member's notes (Section 3.1)	Kept on the task list while the ward account is active, like any other task, and deleted when a leader deletes them. Deleted immediately when the bishopric deletes the member's record (the Delete member action) or the member's record is removed from BishOps. The automatic deletions above for members who have moved out, and for notes about a person typed by name, remove the notes but not the tasks created from them. Deleted with the ward account
Covenant Path notes about a person typed by name rather than chosen from the ward roster (Section 3.1)	Deleted automatically 24 months after the date of the contact the note records, or immediately when the Covenant Path entry is deleted
Interview-request contact details — email, phone, note (Section 3.14)	Cleared automatically 90 days after the request is closed or converted to a scheduled interview; cleared immediately if linked to a member whose record is later erased
Appointment-booking contact details — email, and, on the shared sign-up link, phone (Section 3.14)	Cleared automatically once the appointment is marked completed or declined
Phone notification delivery address, keys and browser identification string (Section 3.15)	Deleted immediately when the leader turns notifications off on that device, automatically when the push service reports the address is no longer valid, and with the leader's account
Record of reminders already sent (Section 3.15)	Deleted automatically after 30 days; kept only to prevent duplicate reminders
Notification choices (Section 3.15)	Retained while the leader's account is active; deleted with the account
Founding Wards requests and setup-call scheduling details (Section 3.16)	Deleted automatically 90 days after the last activity on the request; a request with a setup call still scheduled is not deleted; a request approved as a Founding Ward is kept as the record of that grant
A member deleted by the bishopric (the Delete member action)	Everything BishOps has linked to the person is deleted or unlinked: their interviews and interview requests, prayer list entries, speaking and prayer participation records, calling pipeline items and calling history, tasks about them, meeting attendance, and copies kept by roster imports, along with the entries described in the rows above. On sacrament meeting programs, music plans and the public bulletin, the person's name and link are removed and the slot is kept with its topic and hymns. Sustainings and releases already completed stay as program history with the name removed. So that a later roster import does not add the person back, BishOps keeps a minimal record of their name and the roster-import matching entries that point to it; BishOps does not display that record anywhere. Text that was typed in without being linked to the member (for example, a name written into a meeting's free-text attendee list) is not found automatically, and the ward can edit it. A deleted member cannot be restored
A ward's paid-feature data after its paid plan ends	Kept for 12 months after the plan ends without being renewed. After that, the data used only by paid features is deleted: the calling pipeline, interviews and temple recommend tracking (including members' temple recommend dates), leadership meetings, tasks, Covenant Path entries and the visit and contact log, the interview-scheduling calendar link, and members' birth year and month. Member names, sacrament meeting programs, and the other data the free plan uses stay for as long as the ward account exists. The ward's leaders are emailed 60, 30 and 7 days before the deletion. Renewing the plan before then keeps everything
Billing record of a ward that paid for BishOps, after the ward account is deleted	Kept for 7 years after the deletion, then deleted automatically. It holds only the ward's name and identifier, the payment processor and its customer and subscription identifiers, the plan, price, billing period and status, the end of the last paid period, and when the ward was created and deleted. It contains no member data and no leader contact details. A ward that never paid through our payment processor has no billing record

When a ward account is deleted, everything the ward entered is deleted with it, including its members, Covenant Path entries, shared and bishopric private notes, the visit and contact log, and tasks (including tasks created from notes). The only thing kept is the billing record described in the table above, and only for a ward that paid for BishOps. When a ward account is closed or data is deleted, records are removed from active storage. However, deleted records persist in automated backups for up to approximately 7 days before those backups are purged. After the backup window expires, the data is permanently inaccessible.

7. Public Bulletin

Each ward may publish a public bulletin accessible at a unique URL. No login is required to view it. Bulletin pages are marked with noindex and nofollow directives and are not intended to appear in search engine results.

Published bulletins contain meeting date and type, speaker names, prayer names, hymn titles, and any other program content the ward chooses to publish. This means names of ward members who are assigned to speak or pray are accessible to anyone with the bulletin URL. Published bulletins also include a link to an announced event's flyer, when one is attached (Section 3.12).

We count the number of visits to each ward's published bulletin so that ward leaders can see how often it is used. Only an aggregate daily count per ward is stored — no information about individual visitors is collected or retained, and no cookies are set. To prevent abuse of the counter, a salted, ward-scoped hash of the visitor's IP address is processed transiently for rate limiting and typically deleted within minutes as bulletin visits occur; it is never stored with the count or used for any other purpose.

Individual members who wish to have their name withheld from published bulletins may request this from their ward leadership. Leaders can enable a per-member privacy setting that replaces the member's name with "Ward Member" on all public bulletin pages.

8. AI Features

BishOps uses Google Generative AI (Gemini) for three purposes: document parsing during data import, powering an in-app help assistant, and internal categorization of feature requests.

No data received from Google Workspace or any other Google API — including the Google Calendar connection described in Section 3.8 — is sent to Gemini or to any other AI/ML model, and none of it is used to develop, train, or improve any AI/ML model. Our use of Google user data adheres to the Google API Services User Data Policy, including the Limited Use requirements. The AI features below operate only on the inputs described in each subsection.

8.1 AI-assisted document parsing

BishOps uses Google Generative AI (Gemini) to parse sacrament meeting planning documents and music planning sheets that ward leaders may upload to import prior planning records into BishOps. Gemini extracts program structure, hymn selections, scheduling content, and speaker or participant names from these documents.

Temple recommend data, dates of birth, interview notes, financial information, and other sensitive member data are not sent to Google Gemini. LCR exports are parsed deterministically using code — no AI model is involved. Member data from LCR never passes through Google Gemini at any point.

8.2 AI help assistant

The in-app help assistant is powered by Google Generative AI (Gemini). The text of the leader's messages and the current session's conversation history are sent to Gemini to generate each response. Ward data, member records, and other ward-specific operational data are not sent to Gemini. Conversation history is not stored on BishOps servers.

8.3 Feature request categorization

Stored feature request text is periodically processed by Google Gemini to assist with categorization and prioritization. Only the plain text of the request is sent — no ward data or member records.

9. Third-Party Data Processors

Processor	Purpose	Transfer mechanism
Supabase	Database hosting, authentication, and public storage of leader-uploaded event flyer images/PDFs (Section 3.12)	Standard Contractual Clauses (SCCs)
Vercel	Application hosting and delivery	SCCs; EU-based infrastructure available
Google Generative AI	Document parsing, help assistant, feature request categorization	SCCs or equivalent
Google Calendar API	Optional per-leader calendar connection (Section 3.8): reads free/busy intervals from, and writes interview events to, the leader's own Google Calendar (generic by default; a leader may opt in to include the member's name, interview type, and age group). Also creates the event and Google Meet link for a Founding Wards setup call on the founder's own calendar (Section 3.16)	SCCs or equivalent; governed by Google's API Services User Data Policy (Limited Use)
Functional Software, Inc. ("Sentry")	Error monitoring (Section 3.5): receives technical error reports (error type, shortened message, stack trace, page path, browser and device type), sampled page-timing data, and, only when an error occurs, a masked session replay in which all text and inputs are hidden. Configured to strip URL query strings, request bodies, cookies, and headers and not to attach user identities, so that member data is not sent; reports are kept up to 90 days	SCCs
Resend	Transactional email delivery, including confirmation/reminder emails to an address someone provides through a public appointment form (Section 3.14) or the Founding Wards request form (Section 3.16)	SCCs
Google Workspace	Email service for @bishops.app addresses	SCCs
Browser push services (for example Google for Chrome and Android, Apple for Safari and iPhone)	Delivering the phone notifications a leader turns on (Section 3.15); chosen by the leader's browser, not by BishOps. Notifications are end-to-end encrypted and contain no member names or interview details	Not a BishOps-selected processor; the leader's browser maker operates the service under its own terms
YouTube (Google)	Privacy-enhanced video player for in-app tutorials, loaded only when a leader clicks play (Section 3.9)	Not a BishOps-instructed processor; the leader's browser connects to YouTube directly under YouTube's own privacy policy

BishOps staff have technical access to ward data at the infrastructure layer as necessary to operate and maintain the platform. All such access is governed by a written Staff Data Access Policy, requires mandatory acknowledgment before access is granted, and is automatically logged with timestamp, ward name, and page path. Staff may access ward data only to investigate a reported technical issue, run a database migration, debug a defect, or comply with a legal obligation.

10. Security

Current security measures include:

• All data in transit is encrypted using TLS
• Data at rest is encrypted by Supabase (PostgreSQL with encryption at rest)
• Row-Level Security (RLS) enforces tenant isolation at the database layer
• Authentication via email/password, magic link, or Google OAuth
• Role-based access control limits what each user can see within their ward

11. Your Rights

BishOps does not currently serve wards in the EEA or UK. The rights below apply to the extent required by other applicable data protection laws and will apply fully when BishOps expands to those regions.

• Right of access: You may request a copy of the personal data held about you.
• Right to rectification: You may request correction of inaccurate data.
• Right to erasure: You may request deletion of your personal data, subject to legitimate interests in retaining operational records.
• Right to restriction of processing: You may request that we restrict processing of your data in certain circumstances.
• Right to data portability: Where applicable, you may request your data in a structured, machine-readable format.
• Right to object: Where processing is based on legitimate interests, you have the right to object on grounds relating to your particular situation.
• California residents (CPRA): You may direct BishOps to limit use of sensitive personal information to what is necessary to perform the services described in this policy.
• Virginia residents (CDPA): You have rights of access, correction, deletion, portability, and opt-out of sale or profiling. We will respond within 45 days as required.

Requests to see, correct or delete notes about a member — including Covenant Path entries, visit and contact log entries and the tasks created from them — go through the ward's bishopric. The bishopric can view everything BishOps holds about a member, including the bishopric's private Covenant Path notes, and responds to the request as the controller of that data.

To exercise your rights, contact your ward's leadership for member record requests, or contact privacy@bishops.app for leadership account data or if your ward is unresponsive. We will respond to requests received at privacy@bishops.app within 30 days.

12. Children's Data

BishOps stores birth year and birth month (not full date of birth) for members in a ward's member list, which may include minors. All data is entered by adult ward leaders acting in their ecclesiastical capacity — BishOps does not collect data directly from minors. The same rights described in Section 11 apply to data about minors; a parent or legal guardian may exercise those rights on behalf of a child. Covenant Path entries and visit and contact notes can concern youth and children in the ward. They carry the same access limits as for adults (Section 3.1): they are visible only to the leaders described there, never on the public bulletin, and the bishopric-only private notes are visible only to the bishopric office. Requests about them are made through the ward's bishopric (Section 11).

13. Use of Data — Restrictions

BishOps uses ward data solely to provide and operate the platform. We do not:

• Sell member data to any third party
• Use member data for advertising, marketing, or user profiling
• Share member data with any party not listed in Section 9
• Use member data to build profiles unrelated to the ward's ecclesiastical operations

14. LCR-Derived Data and Church Policy

Ward leaders who import data from LCR do so using their own authorized access to that system. BishOps does not access LCR directly. BishOps is not affiliated with, endorsed by, or reviewed by The Church of Jesus Christ of Latter-day Saints. BishOps is an independent tool that ward leaders may choose to use in the course of their responsibilities.

15. Data Breaches and Incident Notification

In the event of a personal data breach, we will notify the relevant supervisory authority within 72 hours where required, notify affected ward leaders and/or individuals without undue delay where the breach is likely to result in high risk, and comply with applicable US state breach notification laws.

16. Governing Law and Disputes

This policy is governed by the laws of the Commonwealth of Virginia, without regard to conflict of law principles. Nothing in this policy limits your right to lodge a complaint with a supervisory authority.

17. Changes to This Policy

When a material change is made, all authenticated ward leaders will see a notification banner within the BishOps application on their next login. The effective date at the top of this document will be updated with each revision. We do not rely on continued use of the platform as acceptance of a revised policy.

18. Contact

BishOps Software, LLC
privacy@bishops.app