Data Processing Addendum

This Data Processing Addendum (“DPA”) governs how Rewind processes personal data about a Church's congregants and members on the Church's behalf. It supplements the Privacy Policy (which speaks to individuals) and is accepted by a Church administrator when the Church is set up.

Roles

For personal data about the Church's congregants and members, the Church is the controller and Rewind is the processor. We process that data only on the Church's documented instructions — which, for the standard product, are the features the Church enables — and for no independent purpose.

What we process

• Sign-in identity (Google profile or email) of the Church's users.
• The questions users ask and the AI's answers.
• Devotional progress (which days a user marks complete).
• Bookmarks and saved items.
• A push-notification delivery address, if the user turns push notifications on in their browser.
• Problem reports a user submits, including their identity.

Sermon Content itself (recordings, transcripts, and AI derivatives) is covered by the Content License Grant, which sets out what we may do with it. The providers we use to do that work are listed below, alongside the providers that handle congregant data.

Purpose limitation and isolation

We use congregant data only to operate the product for the Church. Each Church is a separate tenant, and data is isolated at the database level by row-level security so one Church cannot see another's data. Errors are reported to our monitoring provider with credentials and identifying tokens scrubbed.

Subprocessors

We use the following subprocessors to provide the service — for congregant data and for sermon Content alike. Each processes only what is needed for its function:

• Anthropic — generating AI overviews, devotionals, guides, and answers. Receives sermon transcripts, and the questions congregants ask along with the conversation they are part of.
• OpenAI — text embeddings for search and retrieval. Receives sermon transcripts and the search questions congregants type.
• Deepgram — speech-to-text transcription. Receives sermon audio.
• api.bible — Bible passage text.
• Google — sign-in (OAuth) identity, and profile images where a congregant signs in with Google.
• YouTube (Google) — sermon artwork and embedded video playback. When a congregant views a page showing sermon artwork, or plays a video, YouTube receives their IP address; playing a video also sends playback interaction data from the browser.
• Google Fonts — where a Church has chosen a web font for its branding, congregants' browsers load it from Google, which receives their IP address.
• Hosts the Church itself chooses — a Church's logo is loaded from wherever the Church hosts it, and where a sermon plays from the Church's own podcast or media host, the audio streams to the congregant's browser from that host directly. Those hosts receive the congregant's IP address and which sermon they opened. We do not choose them and cannot list them here — they are whichever providers the Church already uses.
• Google Drive and Microsoft OneDrive (including SharePoint document libraries) — where a Church has connected cloud storage as the source of its recordings, we read the files the Church selects. We only ever read them. We request read-only access from Microsoft; Google's per-file permission also allows editing, so its consent screen says so, but we never write to or delete anything in the Church's storage.
• Sentry — error monitoring (scrubbed).
• Render — application and database hosting.
• Cloudflare R2 — object storage. Holds the audio we keep in order to process a sermon, media a Church uploads directly, and generated media (e.g. shareable clips). A video imported from cloud storage is deleted once its audio track has been extracted.
• Resend — delivery of sign-in links and notification email. Receives the recipient's email address and the message.
• Push services (Google, Mozilla, Apple, or whichever operates the congregant's browser) — where a congregant turns on push notifications, their browser gives us a delivery address at that service and we send the notification through it.

We will give the Church a reasonable way to learn of changes to this list before a new subprocessor begins processing congregant data or Content.

Security

We maintain technical and organizational measures appropriate to the data, including tenant isolation via row-level security, encryption in transit, least-privilege database roles, and scrubbed error reporting. Access to congregant data is limited to what the product requires.

Data-subject rights

We support the Church in responding to congregant requests to access or delete their data. A user may delete their own account from settings; on deletion their conversations, devotional progress, bookmarks, and preferences are hard-deleted, and problem reports are retained for the Church's quality history but permanently unlinked from the user's identity.

Breach notification

If we become aware of a personal-data breach affecting the Church's congregant data, we will notify the Church without undue delay and provide the information the Church reasonably needs to meet its own obligations.

Return and deletion on termination

On termination, or at the Church's request, we will delete or return the Church's congregant data, subject to routine backups that age out and to records we must retain by law.

Version dpa.v2 · Last updated 2026-08-03.