Working document · 2026 · Not legal advice

This maps Safe Messaging against the guidance reviewed for this work — the Church of England, Methodist, Baptist Union, Catholic (England & Wales) and Church of Scotland codes, and the independent body thirtyone:eight. It is deliberately honest about where the guidance is cautious. It is a tool to inform your own risk assessment, not a substitute for it, and not a safeguarding sign-off.

Necessity and proportionality. thirtyone:eight starts from one question — is this contact necessary, proportionate and risk-assessed? — and expects a per-church risk assessment, not a turnkey tool. Use this sheet to inform that assessment.

Insurance. Ecclesiastical/Benefact sets no separate rules for messaging; cover follows your denomination's safeguarding policy and DBS practice, so any use that departs from your Code could affect your cover.

↑ Back to contents

Working document · 2026 · Not legal advice

The rule

PECR governs electronic marketing. Service (operational) messages are generally permitted; direct marketing requires consent and an opt-out. With the DUAA change, the penalties for getting marketing consent wrong are far higher than the old £500,000 cap.

Hubb's position

• Hubb sends service messages only. The only messages the platform itself sends to users are service/operational messages; Hubb does not send direct marketing on its own behalf.
• Consent and messaging-channel configuration. The platform provides a comprehensive consent and messaging-channel configuration available to all sites. Site administrators (as controllers) configure the consent and channel subscriptions they collect, and send their own messages through the correct channels accordingly.
• Revocation. Users can revoke their consent at any time.
• Safe Messaging notifications are service messages — they prompt approval of, or deliver, an approved pastoral message; they are not marketing.

Residual responsibility

Because Hubb provides the tooling and itself sends only service messages, the PECR position for Hubb is covered. Where a church (controller) sends its own "news and updates," that church is responsible for drawing the service-versus-marketing line and using the consent configuration correctly; Hubb's role is to provide and maintain the configuration that lets them do so.

↑ Back to contents

Working document · 2026 · Not legal advice

Purpose and scope

This policy governs the use of Safe Messaging — one-way, text-only pastoral messages from authorised leaders to children, under parental approval and independent safeguarding oversight. It sits alongside each church's safeguarding policy and denominational code and does not replace trained people or face-to-face care.

Who may use it

• Only leaders the church has authorised, who are appropriately vetted (including DBS as required by the denomination).
• The church authorises which leaders may use the feature and which children they may contact.
• A child can be contacted only where their parent or guardian has enabled it; family/guardian links are set by church administrators or by the parent at registration.

How it works

• One-way: children cannot reply through the tool.
• Parent approval: every message is routed to the parent and delivered only on approval; an unapproved message expires.
• Independent oversight: the church Safeguarding Lead has standing visibility of messages across all leaders and children — the "second key".
• Text-only: no images or video.
• Audited: who sent each message, what was said, when, and who approved or rejected it.

Acceptable use

• Keep messages purposeful and age-appropriate — encouragement, check-ins, birthdays — not open-ended back-and-forth.
• Never use the tool to arrange private or unsupervised individual contact, or to move conversation onto personal accounts.
• Never replace, and do not let it discourage, face-to-face pastoral care.

Primary-age children

Some denominational guidance advises against direct electronic communication with primary-age children. Churches should apply tighter, parent-directed defaults for this group and may choose not to enable it. By default, under-13s have no login of their own and a parent views messages through the parent's account; a church can enable under-13 self-login only by deliberate choice and with the extra safeguards in place.

Disclosures and welfare concerns

Any welfare concern is handled through the church's normal safeguarding procedures, exactly as for any other interaction, with the additional signal of a parent's rejection note, which is actively reviewed and acted on.

Offboarding

The church manages removal of access: when a leader leaves a role, or a parent withdraws permission, access is revoked promptly and the audit record retained per the Retention procedure.

↑ Back to contents

Working document · 2026 · Not legal advice

Purpose

The Data Protection Act 2018 requires an Appropriate Policy Document where a controller relies on certain Schedule 1 conditions to process special-category or criminal-offence data — in particular the safeguarding of children condition (Schedule 1, paragraph 18). This template documents how that processing meets the Article 5 principles. It is intended for adoption by each relying church (controller) and to sit alongside Hubb's processor terms.

1. Data and conditions relied on

• Religious belief (Article 9 special-category): participation in a church app and faith-based messages may reveal a child's religious belief. Condition: the not-for-profit body with a religious aim (Article 9(2)(d)) for the church's own members and regular contacts, with no disclosure outside the body without consent.
• Safeguarding of children (substantial public interest, Schedule 1 paragraph 18): the Safeguarding Lead's review of messages, and acting on a parent's rejection note, to protect children from harm. This condition requires this Appropriate Policy Document.
• Where any criminal-offence data arises from a safeguarding concern, it is processed only under an appropriate Schedule 1 condition and these same safeguards.

2. Compliance with the principles

• Lawfulness, fairness, transparency: processing is explained to parents and age-appropriately to children; purposes are limited to pastoral contact and safeguarding.
• Purpose limitation: data is not used for marketing or any incompatible purpose.
• Minimisation: text-only messages; no images; access to message content limited to the parent and the appointed Safeguarding Lead.
• Accuracy: family/guardian links are maintained by church administrators or parents at registration.
• Storage limitation: retained only while the relationship is active; deleted on leaving — see the Retention and Data-Subject-Rights procedure.
• Security: UK hosting, no international transfer, access controls, audit logging.

3. Retention and review

This document is retained while the processing continues and for the period required after it ends, reviewed at least annually and on any material change. Owner: [church DPO]. Hubb maintains the platform controls that give effect to it.

↑ Back to contents

Working document · 2026 · Not legal advice

What is stored

Message content; the audit record (sender, timestamp, approving or rejecting parent, rejection note); and the family/guardian and authorisation links needed to operate the feature.

Retention

• Records are retained for safeguarding purposes while the relationship is active — that is, while the church continues to use the platform
• If the church ceases to use the Hubb platform, records may remain in secure backups for up to 12 months, after which they are permanently deleted

Data-subject rights

• Children, and parents on their behalf, can request access, rectification and erasure. Requests go to the church as controller; Hubb actions them on instruction.
• Because every message is stored, there is a workable route to locate and export or delete a specific child's records.

Security

Data is hosted in the UK with no international transfer, with access controls and audit logging. Access to message content is limited to the parent and the appointed Safeguarding Lead. Breaches are handled under Hubb's incident procedure and reported to controllers without undue delay.

↑ Back to contents