Data Processing Agreement — Velyora attendance check-in service

1. Roles, subject matter and scope of the processing

The subject matter of the processing is the operation of the hosted attendance check-in service for the Organisation. The processing lasts for as long as the account exists, together with any post-cancellation retention window and any further period needed to complete deletion. At the end of that period the Provider deletes the Organisation’s personal data and retains no copy. The Organisation may instead require return of the data, which is delivered as an export the Organisation must decrypt on its own device using its own passphrase.

The nature of the processing is the storage, transmission, organisation, structuring, retrieval, deletion and export of attendee personal details, which are encrypted on the attendee’s device before they reach the Provider, together with the processing in readable form of the surrounding structure and record-keeping fields the service needs in order to function. The purpose is limited to providing the service. The Provider processes personal data only on the Organisation’s documented instructions, and use of the software as configured by the Organisation is such an instruction. Any use of the Organisation’s data beyond providing the service is a breach of these processing terms and makes the Provider a controller in respect of that use.

The personal data processed fall into two sets. Encrypted on the attendee’s device and unreadable to the Provider: attendee identity and contact details, birthday (day and month, without year), free-text messages, records the Organisation writes about an attendee, minor and visitor status, and gathering names. Held in readable form: the Organisation’s own identity and contact details, gathering schedules, attendance records and figures derived from them, relationships between attendees, account and helper identifiers, sign-in records and billing records. The categories of data subject are attendees, including children checked in by an adult, the account holder, and helpers.

Attendance at a religious gathering is data revealing religious belief within Article 9(1) GDPR, and that classification extends to the whole record, including the parts held in readable form. The Organisation is responsible for identifying and documenting a condition under Article 9(2) GDPR. These descriptions may be relied on for the Organisation’s own record of processing activities under Article 30(1) GDPR. The Provider gives the Organisation advance notice, on the same terms as a sub-processor change, before adding a new category of personal data or moving any data out of the encrypted set.

The Organisation is the controller of attendee data and the Provider is its processor for that data. The Provider is an independent controller of account and billing data, of sign-in records, of the two optional consents, and of any review an authorised person writes for publication by the Provider. Requests from attendees about their own data are answered by the Organisation. If the Provider receives such a request it forwards it to the Organisation without undue delay and does not answer it itself. Requests about account, billing or sign-in data are answered by the Provider. Where a request concerns both, each party answers for its own part. For a personal data breach affecting attendee data the Organisation decides on notification to a supervisory authority and to the people affected; for a personal data breach affecting only data the Provider controls, the Provider notifies.

2. What the encryption does and does not protect

The Provider can delete, structure and export attendee records but cannot read, correct or produce the encrypted personal fields in readable form for anyone, including a court or supervisory authority, and assists only with operations that do not require reading them. The Organisation is the point of contact for access, rectification and portability requests concerning attendee data, and must retain a device and passphrase able to produce readable exports for as long as it may need to answer one.

A disclosure of the stored data would still show that a named religious organisation holds a record for a person identified by an opaque identifier, and attendance timing can often narrow that record to an individual. The Organisation must assess this residual disclosure in any personal data breach assessment and must not treat encryption of the personal fields as answering it.

Encryption protects attendee details held by the Provider. It does not protect details submitted while the service itself is compromised. The Organisation must describe the protection to attendees accordingly. It must not tell attendees that incoming records are readable only by people the Organisation has authorised, because that is not true while the service itself is compromised.

3. Credentials, recovery sheets and device security

The Provider never receives the account passphrase, holds no escrow and cannot reset or override it. If it is lost and no valid recovery sheet exists, the encrypted data can never again be read by anyone. The Provider has no technical means to produce it, and cannot do so in response to any request, including a court order. This is a limitation of the architecture, not a refusal to comply with legal process. Custody of the passphrase is the Organisation’s own responsibility.

A recovery sheet is a full credential: whoever holds one can sign in and read the whole congregation’s records. Loss of a sheet is a security incident and must be handled as one. Changing the passphrase invalidates every sheet printed before it.

Endpoint security is the Organisation’s responsibility and cannot be passed to the Provider. A compromised device is the principal route by which readable attendee data already held can be obtained, and every additional person the Organisation authorises is an additional place where that data exists. The service documentation describes credential and session behaviour in detail.

Removing a helper ends their future access but does nothing about what they have already read. Where a helper departs under suspicion, the Organisation must assess the departure as a possible disclosure of personal data. A helper’s view and export cover only their own subset of records, so an export offered to an attendee or an authority as a complete record must be produced by the account owner.

The Organisation is responsible under Article 5(1)(d) GDPR for the accuracy of the records it holds, including reviewing unverified rows, merging duplicates and purging records created by strangers, using the tools the service provides. The service documentation describes how check-in, identification and merging behave.

4. Lawful basis, agreement and attendee-facing wording

The attendee-facing agreement wording and the Article 13 privacy information belong to the Organisation and are its responsibility, including the identification of the lawful basis and of its own supervisory authority. The wording supplied with the software is a placeholder, does not satisfy Articles 13 and 14 GDPR, and the software does not prevent check-ins being accepted against it. The Organisation decides which languages it maintains those documents in and is responsible for the consequences of a reader’s language being absent.

Where the Organisation relies on its status as a religious body, a first-time visitor is not yet a member or a person in regular contact with it, so their first record falls outside that basis until the Organisation verifies them. Newcomers must be verified promptly. Where one person checks another in, nothing verifies that the second person accepted the attendee-facing agreement recorded for them. Where one person checks in several members of a household at once, the Organisation must not treat that single submission as acceptance of the attendee-facing agreement by each person named in it.

Every version of an attendee-facing document that a person accepted is retained, together with a cryptographic digest of its text, and both appear in the export, so the Organisation can demonstrate to a supervisory authority which text a given person accepted and that it has not been altered since.

5. Retention, deletion and erasure

On the free plan, an attendee record and all its check-in history are deleted automatically 48 hours after the attendee record was first created. The Organisation must not promise its members a record it will not hold, and must export anything it needs to keep before that period expires.

An account with no authorised activity for 12 months is deleted in full, unless it is currently paying or is still within a retention window earned by past payment. Deletion removes the profile, the settings, the gatherings and every attendee record, and none of it can be recovered. Warning messages are sent beforehand to the account owner and to accepted helpers who are not suspended, provided the account owner’s address has been confirmed. Signing in is what prevents the deletion; reading the warning does not. The Organisation must export its data before any planned period of inactivity.

An Organisation that has paid keeps its data for a window after the subscription ends. The length of that window is earned from the number of periods paid for, at 30 days for each, subject to a minimum of 30 days and a maximum of 90 days, and it runs from the date the subscription first ceased to be active. For an Organisation that has paid, the current end date of the window is shown in the account profile, together with the interval at which the deletion process runs. An Organisation that has never paid has no such window. Records must be exported before the window closes.

Erasing a person removes their personal data and every route back to the record, leaving the attendance rows standing as an anonymous count with the basis on which each was collected. The same operation erases every attendee whose check-in that person recorded, including children. The effect is immediate and permanent, and no party, including the Provider, can reverse it. The Organisation is responsible for confirming the identity of a person requesting erasure and for informing the affected people or their guardians, and the Provider acts only on the Organisation’s instruction.

The service arranges facts the Organisation recorded and produces no prediction and no system-generated evaluation of a person. Any conclusion drawn from a display is the Organisation’s own, and the Organisation must keep its own record of any pastoral follow-up carried out.

6. Sub-processors, transfers, security, breach, audit and assistance

The Provider engages OVH Hispano SL for hosting, Stripe Payments Europe, Limited for payment processing, and Sendinblue SAS (Brevo) for email delivery. Their purposes, locations and transfer safeguards are set out in the sub-processor list published at https://velyora.app/subprocessors, which is the authoritative statement of them. No attendee data reaches the payment processor, the mail service sees account and helper email addresses only, and no sub-processor can read the encrypted personal fields of an attendee record.

The Organisation gives general written authorisation under Article 28(2) GDPR for the Provider to engage sub-processors. The Provider must give at least 30 days’ notice by email to the account owner before adding or replacing a sub-processor, must impose the same data protection obligations on it by contract, and remains fully liable to the Organisation for its acts and omissions. The Organisation may object within the notice period on reasonable data protection grounds. If an objection cannot be resolved, the Organisation may terminate and receive a refund of the unused part of any prepaid period. That termination and refund is the whole of the remedy for an unresolved objection, and the Organisation cannot require the Provider to keep the previous arrangement.

The Provider implements and maintains technical and organisational measures appropriate to the risk under Article 32 GDPR. These comprise: end-to-end encryption of attendee personal fields, which the Provider cannot decrypt; encryption of data in transit and at rest; access confined to the account owner and the helpers the Organisation authorises; rate limiting and lockout on sign-in; segregation of each Organisation’s data; regular backups; logging of sign-ins; and a confidentiality obligation binding everyone the Provider authorises to process the data. The Provider may change a measure provided the level of protection is not reduced, and will describe its current measures to the Organisation on request.

The Provider notifies the Organisation without undue delay after becoming aware of a personal data breach affecting the Organisation’s personal data, and provides the nature of the breach, the categories and approximate number of records concerned, the likely consequences so far as known, and the measures taken. The Provider will not judge on the Organisation’s behalf whether a breach carries a risk to individuals. That assessment, and any onward notification to a supervisory authority or to the individuals concerned, is the Organisation’s own and its time runs from the moment the Organisation is told. The Organisation must be able to receive such a notification and act on it quickly, including outside working hours.

Under Article 28(3)(h) GDPR the Organisation may verify the Provider’s compliance with these processing terms. An on-site or third-party audit may be required once in any twelve-month period, and at any time after a personal data breach or on the instruction of a supervisory authority, on 30 days’ notice, at the Organisation’s cost, by an auditor who is not a competitor of the Provider and who signs a confidentiality undertaking. No audit can produce the encrypted personal fields of an attendee record in readable form. The Provider must also make available all information necessary to demonstrate compliance with Article 28, and must inform the Organisation if an instruction appears to the Provider to infringe data protection law.

The Provider must assist the Organisation, so far as the architecture allows, with data subject requests, with the security of processing, with breach notification, and with any data protection impact assessment or prior consultation. That assistance is limited by design: where a task requires readable attendee data, the Provider can only route the request to the Organisation. Routing and documentary assistance are provided at no charge. Assistance beyond routing and documentation may be charged at 90 euros per hour. The Organisation must resource these tasks itself.

7. Continuity, termination and complaints

The Provider is one person, so illness, death or a decision to stop trading can bring the service to an end. Nobody who inherits or acquires the infrastructure can read the encrypted personal fields of an attendee record.

Confidentiality, the limits of liability, the governing law and forum, any payment obligation already accrued, and the duty to delete or return personal data continue after termination. These processing terms continue to apply for as long as the Provider still holds any of the Organisation’s personal data, including throughout a retention window and throughout a deletion still in progress. The Organisation may hold the Provider to them after cancellation.

The Provider’s lead supervisory authority is the Agencia Española de Protección de Datos (AEPD), C/ Jorge Juan 6, 28001 Madrid, www.aepd.es. An Organisation established in another Member State may complain instead to its own national supervisory authority, which will coordinate with the AEPD. Complaints about attendee data lie against the Organisation, which is responsible for the content of the privacy information it gives to attendees, including the identification of itself as controller and of its own supervisory authority.