Data Protection for Churches

Last updated 17 September 2026

For church leaders deciding whether to bring an assessment to their congregation, and for denominational data protection officers reviewing whether that is permissible. It is more detailed than the Privacy Policy because your questions are more detailed.

1. The question you are actually asking

You want to know whether asking your congregation or leadership team to complete an assessment creates a data protection problem for you.

There are two ways to run one, and they have different answers, so this document treats them separately. Individually, nothing is transmitted anywhere and there is no processing by us to assess. As a group reading, responses are collected on our infrastructure, encrypted with a key we do not hold.

2a. What happens to an individual response

A person opens the assessment in their browser. The questions and the scoring code are delivered with the page. They answer. Their answers are written to their own browser's local storage. The score, the band and the report are computed on their device.

At no point is an answer, a score or a report transmitted to Kingdom Vanguard, to a server, or to any third party. There is no submit step, because there is nowhere for it to submit to. You can verify this yourself — open your browser's network inspector and complete the assessment; no request is made.

2b. What happens to a group-reading response

A group reading exists so that leadership's account and the congregation's account can be compared. That requires collection, so this path does involve a server. The design is built so that collection costs the church nothing in candour.

• Encryption happens before transmission. The facilitator's browser generates an AES-256-GCM key. It is placed in the fragment of the invitation link — the part after the `#`. Each respondent's browser encrypts their answers with that key and posts the ciphertext.
• The key does not reach us unless you send it. A URL fragment is not sent to a server as part of a web request. This is browser behaviour, not a policy of ours, so the key cannot arrive here by accident: it is absent from our server, its access logs and its backups.
• The one way it can reach us is if you decide it should. The facilitator's own report carries a control marked Share this reading with Kingdom Vanguard. Pressing it sends us the key, and from that moment we can read the pooled result — the same pooled result you are looking at, and nothing finer. It does not give us any respondent's individual answers, because the server never held those separably and the pool cannot be taken apart.
• You can withdraw it, and withdrawal deletes the key rather than hiding it. The same control turns it off, and the key is removed from our store rather than marked inactive. What it cannot do is un-read a report someone has already read. We would rather say that plainly than let withdraw sound as though it reaches backwards.
• What is stored per response: the ciphertext, the initialisation vector, which respondent group it belongs to, and the arrival time rounded to the minute. That is the whole record. No name, no email, no IP address, no user agent, no cookie, no session, no account, no per-respondent identifier of any kind.
• Two categorical questions travel inside the ciphertext: the respondent's part in the church and how long they have been there. They are not scored. A sub-group of fewer than eight is never reported separately, because role and tenure in combination identify a person in a small church.
• Suppression is enforced at the server, not in the report. Below a group's threshold — eight for a congregation, four for a leadership team — the ciphertexts for that group are not sent to anyone, including the facilitator. There is nothing to decrypt, rather than something the report has been asked not to show.
• Released responses are shuffled, because order of arrival is itself a correlation handle in a small room.
• Retention: a reading stops accepting responses after 120 days and is destroyed in full at 180 days from opening, by a sweep that runs on the service itself rather than by anyone remembering. The facilitator can destroy it sooner from their own console, and can export everything held for it at any time. Both are controls in the interface, not an email address.

2c. The one record that is personal data

The person who opens a reading supplies their name, email, church and position, about themselves, so that we can contact them. We hold that. We are naming it here because a document that claimed we hold nothing would be false, and because you should be able to find our least convenient fact without looking for it.

It is stored separately from the responses and is never returned by the endpoint that serves a reading, since everyone invited to a reading holds its code. It is deleted with the reading.

Note what follows: the facilitator is identifiable, and the respondents are not. If that is the wrong way round for your church — if the person opening the reading does not wish to be known to us — ask a denominational colleague to open it, or write to us and we will arrange it another way.

3. Who is the controller

For individual use: because we neither receive nor determine the purposes of any processing of your congregation's responses, we are not a controller or a processor in respect of them. We supply a tool that runs on the respondent's own device, in the way that a printed questionnaire is not processed by its printer.

For a group reading: the church that opens the reading determines why it is run, who is asked, and what is done with the result. We provide the collection and storage on its instructions and cannot read what we store. Our own view is that this makes the church the controller and Kingdom Vanguard its processor for the responses, and makes us the controller of the facilitator's contact details, which we hold for our own purpose of being able to reach them.

If you collect completed reports from your people by other means — by asking them to email you their results, print them, or read them out in a meeting — you become the controller of that collection, and your own denominational data protection arrangements apply. That is a real obligation and worth thinking about before you ask.

This is our own reading of the regulation, not a settled legal ruling. If your denomination requires a written processing agreement under Article 28 before you run a group reading, write to us before you open one and we will arrange it.

4. Running an assessment well

Whether or not the law requires it, these make for a better process and more honest answers.

• Tell people what it is for before you ask, and what you will do with the results. An assessment introduced without explanation produces defensive answers, which produce a useless score.
• Decide who will see the report before anyone answers, and tell them. Changing that afterwards is the most damaging thing a church can do with these instruments.
• Do not ask for names. The instruments do not, and neither should you. The dimensions most worth measuring are exactly the ones people will not answer honestly if they can be identified. If you find yourself wanting to know who said what, that impulse is itself one of the findings.
• Send the invitation link, not the facilitator link. They are different links and the page labels which is which. The facilitator link carries the key and the delete token; sending it to the congregation gives everyone the ability to open the report and to destroy the reading.
• Honour the minimums. Below eight congregational respondents, or four on a leadership team, a group score can identify individuals by subtraction. With numbers that small, discuss the questions together rather than scoring them separately.
• Never use results in an employment process. Beyond the ethical problem, doing so after inviting anonymous participation may itself breach data protection law, and it will end honest answering in your church permanently.

5. What we said we would do, and what we did

An earlier version of this document promised that if responses were ever stored, congregational responses would carry no link to a user account — enforced by the schema rather than by a policy someone could later change — that group results would be gated behind a minimum respondent count, and that this document would be rewritten before it launched. We invited you to hold that against us.

Group readings now exist. Against each promise:

• No link to a person. Kept, and more strongly than promised: a response record has no identity field at all, so there is nothing to link. There is no user account in the product.
• Gated behind a minimum count. Kept, and moved from the report to the server, so it is not a display rule that a future version could relax.
• Rewritten before launch. This is that rewrite. Sections 2b and 2c are new, and the Privacy Policy no longer claims we receive nothing.
• Not promised, and added: the responses are encrypted with a key that cannot reach us by accident, so the default is cryptographic rather than procedural.
• Amended 17 September 2026. A facilitator can now hand us that key deliberately, from a control on their own report, so that we can read the pooled result and advise on it. Until they do, we hold ciphertext we cannot read. The earlier wording stated this without the exception, which was true when it was written and is not true of a product that has this button, so it has been corrected here rather than left to age.
• Not promised, and added: a fixed retention window that runs whether or not anyone is watching, and export and deletion as controls in the interface rather than as a request to us — Article 15 and Article 17 as buttons.
• Promised and not yet done: an Article 28 processing agreement. See the bracketed note in section 3.

6. Contact

Questions from church leaders, denominational data protection officers or diocesan registrars: danielloverde@kingdomvanguard.com. We would rather answer a detailed question before an assessment runs than a complaint after it.