Version 1.0 of 16 October 2026 – guidance, not legal advice for your case. For organizations that consider using Contals for pastoral care follow-up, prayer requests, children’s and youth ministry or social support. A data protection impact assessment (DPIA) is required for processing likely to result in a high risk (GDPR Art. 35, revFADP Art. 22, KDG and DSG-EKD accordingly).
1. First decide what does not belong in Contals
| Do not store | Why | Use instead |
|---|---|---|
| Counselling content, confessions, anything under pastoral or professional secrecy (Art. 321 Swiss Criminal Code; church law) | A US-related provider cannot be treated as a bound auxiliary for these secrets; Contals has no customer-held-key encryption | Paper or a dedicated encrypted system kept by the pastor; in Contals at most “follow-up visit due” without content |
| Safeguarding allegations, investigations, incident reports about children | Highest risk, criminal-law relevance, strict access needs | Your safeguarding process and its dedicated system |
| Health records, diagnoses, medication, allergies of children | Health data of vulnerable people | Registration forms kept by the camp leadership; only “see medical sheet” on a card |
| Membership registers with denomination, baptism and family data | Belongs to the church register / church management system | ChurchTools or your register |
| Public bodies under Swiss cantonal law: any special personal data | Cantonal supervisors require encryption with the body’s own keys for US-related providers (privatim 2025-11-24; Zurich DPO 2026-02) | Non-sensitive coordination only, after your own assessment |
2. Recommended settings for a sensitive board
| # | Setting | How (status 2026-10-15) |
|---|---|---|
| 1 | Private board, named members only, no workspace visibility | New boards are private by default; check Board settings → Members → Visibility: Private |
| 2 | No guests; volunteers only as contributors where needed; review members every quarter | Board settings → Members; access ends immediately when someone is removed |
| 3 | Mark the board confidential: no titles in links, download names or tab titles; no content in chat notifications or inbox entries; e-mails name it only as “a confidential board”; never sent to AI; not available through the API, MCP or AI agents; every opening logged in the audit log | Board settings → Confidential board (board admins). Public pages keep working – see 4a |
| 3a | Organization-wide: “no titles in links” – every board and card link of the organization uses only IDs | Organization settings → Titles in links (owners and admins); old links keep working |
| 4 | Board title without names (“Besuchsdienst Team A”, not “Seelsorge Familie Muster”) | Titles appear in the workspace’s board list and, without 3 or 3a, in links |
| 4a | No public booking pages or date polls on a sensitive board: a booking puts the booker’s name into the card title, and both collect the contact details of people outside the team | Switch the booking and date-poll Power-Ups off, or forbid or turn off their public links |
| 4b | Status updates about the work, not about people: a board’s status (on track / at risk / off track and its text) appears in the board header and on the workspace dashboard of everyone who can open the board | Keep the text factual (“two leaders still missing”), never names, health or pastoral details; delete a wrong update (its text leaves the board history too) |
| 5 | Minimal, coded content: initials or codes, facts instead of opinions, no third-party names, no diagnoses | Agree a writing rule in the team (template in section 4) |
| 6 | No AI features on this board | AI with your own provider is off by default; switch AI off for the workspace that holds sensitive boards and keep comments and names off in the data policy; confidential boards are never sent |
| 7 | No chat notifications (Slack, Teams, Google Chat, Discord) | Do not add channels on this board; confidential boards send no content anyway |
| 8 | No API tokens or agents for this board | A confidential board is not available through the API, MCP or AI agents at all; for other boards tokens act with the creator’s role – restrict them to one workspace or avoid them |
| 9 | Retention: delete (or archive) done cards after the agreed period | Board settings → Retention of done cards: archive or delete done cards a chosen number of days after they were completed; deleting also erases their comments and texts from the board history |
| 10 | Exports only by board admins; store exports encrypted and delete them after use | Exports are audited |
| 11 | Devices: use “shared device” mode on the church office PC; sign out; review signed-in devices | Profile and settings → Signed-in devices and “This is a shared device” (no board copies are kept in that browser) |
| 12 | Individual accounts, no shared logins; remove leavers the same day; two-factor sign-in for everyone | Organization settings → Require two-factor sign-in (an authenticator app or a passkey); with single sign-on and “require SSO” your identity provider’s multi-factor sign-in applies. The audit log shows who changed roles and access |
| 13 | Deleting text: editing or deleting a comment erases its earlier text from the board history, search and exports; earlier card titles and descriptions stay in the history for up to 13 months, and the archive and recovery copies keep everything until their retention ends | Avoid writing sensitive text in the first place, and never in card titles or descriptions (see the TOMs, section 7) |
| 14 | Photos and files: photos of children only with the consent your rules require (parents, or the young person from the age your law sets); prefer no files at all on a sensitive board | Location and camera data are removed from photos automatically when they are uploaded; on a confidential board links carry no file names; deleting a file erases it a day later; files are not part of backups |
3. DPIA checklist
A. Is a DPIA needed? Usually yes if one of these applies (supervisors’ lists also name further cases):
- special categories (religion, health) of many people or in a systematic way
- vulnerable data subjects (children, people in crisis, refugees)
- information under a secrecy duty
- combination of data from several sources about the same people
B. Describe the processing
- purpose of the board, who uses it, which data, about whom (use the records template)
- legal basis per data category (consent? Art. 9(2)(d)? church law?)
- processor and subprocessors (Contals, Cloudflare; see the subprocessor list), storage location, transfers
C. Necessity and proportionality
- could the purpose be reached with less data (initials, no free text)?
- retention period defined and practised?
- data subjects informed (privacy notice), consent recorded where needed?
D. Risks (rate likelihood × severity for each)
| Risk | Typical cause | Contals measures | Your measures |
|---|---|---|---|
| Unauthorized access by members | too many members, leavers not removed | private by default, server-checked roles, removal ends access at once | membership reviews, offboarding |
| Unauthorized access by administrators | workspace admins curious | admins manage private boards without content; break-glass is logged and visible | rule for admins |
| Disclosure via links, notifications, screenshots | names in titles, forwarded links | confidential boards without titles in links, no chat content | neutral titles, confidential flag |
| Lost or shared device | office PC, phone | shared-device mode, remote sign-out, access revocation wipes local copy | device rules |
| Access by foreign authorities | US CLOUD Act at Cloudflare, Inc. | EU storage, opaque identifiers, contractual challenge commitments; no customer-held keys | keep secrets out; minimal content |
| Incomplete deletion | earlier titles and descriptions in the history (up to 13 months); archive and backups | edited and deleted comments erased from the history; deletions applied again after a restore; disclosed retention | avoid sensitive free text |
| Account takeover | weak password, phishing | confirmed e-mail, rate limits, sign-in links, SSO, two-factor sign-in and passkeys | strong passwords; require two-factor sign-in for your organization |
E. Result
- residual risk acceptable? If high: consult the supervisory authority (GDPR Art. 36, revFADP Art. 23) or do not use Contals for this purpose
- DPO consulted (name, date, opinion)
- decision by [responsible person], date, review date (at least yearly or on changes)
4. Writing rule for the team (template)
On this board we write only what the next person needs to act: who (initials), what (task), when. No diagnoses, no family details, no opinions, no names of other people. Anything confidential is told in person or kept in [the pastor’s own notes]. Done cards are archived at the end of each month and deleted after [3] months.