Safeguarding and consent for church youth events: what software can and cannot do

Who actually signs the consent for a child?

The guardian, from their own email, on their own link. When a place is marked as being for someone under 18, the form asks for the parent or guardian's own address — not the address of whoever is booking — and a countersign request is created for that address inside the transaction that confirms the booking.

The distinction is not pedantry. A checkbox ticked by the person booking is that person's commitment; it is evidence about them, not consent from the guardian. Where a church needs to show that a parent agreed, only the parent's own act is worth anything, and the record bindro keeps is of that act: who signed, under what wording, when.

What happens if the guardian never signs?

The child is not admitted. They are left off the offline door list entirely, and a check-in attempt is refused with the reason stated. There is no flag on a screen that a volunteer might or might not notice on a busy morning.

That is the whole design principle: an unsigned consent has to be a refusal rather than a warning, because a warning at a door with forty children arriving in ten minutes is a warning nobody reads. Practically, tell parents to expect the email at booking time, and check the unsigned list the day before rather than on the morning.

• The email goes to the guardian's own address, so collect it accurately.
• Signing is one link and a typed name; it takes a parent under a minute.
• Re-signing does not overwrite the first signature.
• Check the unsigned list the day before, not at the door.
• An adult attendee never triggers a request, so the list stays short and real.

What does bindro do about volunteer safeguarding checks?

It collects a declaration and records a rota. It does not run checks. The safeguarding requirement is a blocking one, so a booking cannot be completed until it is accepted, and the rota records which volunteer holds which role on which session at which event.

What is not there: no DBS or police-check integration, no store of certificate numbers or expiry dates, and no rule that refuses to roster somebody whose clearance is missing or expired. If you need that, keep it where you keep it now and treat the bindro rota as a record of intent. A rota entry also grants no access to anything — permissions come from a person's role in your organisation, never from being on a shift.

Who can see a child's information?

People with a role that allows it, and no automated system at all. Data about a child, and health information such as allergies and access needs, are held as separate classes and are excluded absolutely from analytics exports and from any AI feature. There is no setting that turns that exclusion off, in any vertical, and it is not a preference.

Within the church, access is by role: someone helping on the door does not thereby acquire the medical notes for a holiday club. And a question the form does not declare is rejected rather than stored, so no volunteer can improvise a new field and create an unaudited channel of information about children.

What should our safeguarding policy say about this?

Name the split explicitly, in the policy itself. Something close to: consent is collected and enforced by the registration system, which refuses admission without a guardian signature; volunteer clearance is held and verified by the safeguarding lead, and no software checks it. A policy that says "the system handles safeguarding" is worse than one that says nothing, because it invites everyone to assume the other half is covered.

Then decide who watches the unsigned list, who reconciles the rota against your clearance records, and by when. Those two people are your actual control; everything above is what makes their job smaller.