BishOps Privacy Policy
Last updated: April 29, 2026
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
BishOps does not collect or store member addresses, phone numbers, email addresses, financial records, ordinance records, or membership council records.
3.2 How member data enters BishOps
Member data enters BishOps through two paths:
- Manual entry — leaders type data directly into the application
- 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 or magic link.
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 do not use third-party product analytics or behavioral tracking beyond what Vercel provides as a hosting service.
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.
4. Temple Recommend 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.
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, 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 is 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, DOB, 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 |
| 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 data for platform administration and technical support | Legitimate interests (Art. 6(1)(f)) |
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 |
| Published bulletin records | Automatically unpublished after a maximum of 3 weeks (ward-configurable) |
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.
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.
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 | 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 |
| Resend | Transactional email delivery | SCCs |
| Google Workspace | Email service for @bishops.app addresses | SCCs |
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.
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.
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