Campflow — Tietosuojavaikutusten arviointi (DPIA)

GDPR-asetuksen (EU 2016/679) Art. 35 mukainen arviointi. Koskee Campflow-leirinhallintapalvelun käyttämiä käsittelytoimia, joissa käsitellään alaikäisten henkilötietoja sekä erityisiä henkilötietoryhmiä (terveys, allergiat, lääkitys).

1. Tarvittiinko DPIA?

Kyllä. GDPR Art. 35(3) listaa tilanteet, joissa DPIA on pakollinen. Campflow täyttää useita kriteerejä:

• Alaikäisten henkilötiedot (Art. 8) — pääosa rekisteröidyistä on alle 16-vuotiaita leiriläisiä.
• Erityiset henkilötietoryhmät (Art. 9) — terveystiedot, allergiat ja lääkitykset ovat järjestelmän ydintietoa.
• Suuri mittakaava — palvelua käytetään useissa organisaatioissa, joiden yhteenlaskettu rekisteröityjen määrä on tuhansia.
• Haavoittuva ryhmä — alaikäiset eivät pysty kaikilta osin ymmärtämään suostumuksensa vaikutuksia.

Tietosuojavaltuutetun toimiston julkaisema lista käsittelytoimista, joista DPIA on tehtävä (TSV 2018), tukee tätä arviointia.

2. Käsittelytoimien systemaattinen kuvaus

2.1 Käsittelyn kuvaus

Campflow on selainpohjainen leirinhallintapalvelu (SaaS), jonka avulla seurakunnat, lippukunnat, urheiluseurat ja yhdistykset hallinnoivat lasten ja nuorten leirejä. Huoltaja ilmoittaa lapsensa leirille, järjestäjä ottaa vastaan ilmoittautumiset, kerää tarvittavat lupatiedot, suunnittelee ohjelman ja viestii huoltajille leirin aikana.

2.2 Käsittelyn tarkoitukset

• Leirin ilmoittautumisten vastaanotto ja hallinta
• Osallistujien terveysturvallisuuden takaaminen (allergiat, lääkitys, uimataito)
• Ryhmien, majoituksen ja aikataulujen suunnittelu
• Yhteydenpito huoltajiin (leirikirje, huoltajaportaali, hätäilmoitukset)
• Lakisääteisten velvoitteiden täyttäminen (kirjanpito, työturvallisuus, lääkkeenantoloki)

2.3 Käsiteltävät tiedot

2.4 Tietovirta

1. Huoltaja täyttää julkisen ilmoittautumislomakkeen (ilmo.html) → tiedot kirjoitetaan Firestoreen.
2. Järjestäjä kirjautuu sovellukseen (app.html), näkee ilmoittautumiset, hyväksyy/hylkää, jakaa ryhmiin.
3. Henkilökunta (leiripomo, ohjaaja, EA-vastaava, keittiö) saa rajatun pääsyn rooli-perusteisesti.
4. Huoltajaportaali (huoltaja.html) — huoltaja saa parentToken-linkin sähköpostiin ja näkee leirin aikana lapsensa tilanteen.
5. Cloud Functions hoitavat sähköpostit (Resend), valokuvankäsittelyn (Sharp + EXIF-strippaus) ja AI-toiminnot (Anthropic Claude).
6. Säilytysaikojen päätyttyä tiedot poistetaan automaattisesti porras-mallin mukaisesti (cleanupExpiredData).

2.5 Vastaanottajat ja tietojenkäsittelijät

3. Tarpeellisuuden ja oikeasuhtaisuuden arviointi

3.1 Käsittelyperuste

Pääperuste on Art. 6(1)(b) sopimus (huoltajan ja järjestäjän välinen leirisopimus) sekä terveystietojen osalta Art. 9(2)(a) nimenomainen suostumus, jonka huoltaja antaa ilmoittautumislomakkeessa erillisellä rastilla. Lääkkeenantoloki perustuu Art. 6(1)(c) lakisääteiseen velvoitteeseen (potilasvahinkokäytäntö).

3.2 Tietojen minimointi

• Kerätään vain leiritoimintaan tarvittavat tiedot — ei esim. henkilötunnusta, koulutaustaa tai uskonnollista vakaumusta (paitsi jos seurakunnan oma toiminta perustuu uskonnolliseen ryhmittäytymiseen).
• Ryhmänjohtaja näkee oletuksena vain oman ryhmänsä leiriläisten täydet tiedot. Muiden ryhmien lapset näkyvät anonymisoituna ("Matti V.") esim. majoitustaulukossa.
• Push-ilmoituksissa ei näytetä lapsen nimeä eikä terveystietoa (lukitusnäyttö-suoja).
• AI-toiminnot (esim. ruokailun allergia-analyysi) saavat vain anonymisoidut syötteet — Anthropic-API ei näe lapsen nimeä.

3.3 Säilytysajat (porras-malli)

4. Riskien arviointi

Riskit on arvioitu rekisteröityjen näkökulmasta käyttäen kolmiportaista asteikkoa (alhainen / kohtalainen / korkea), arvioiden todennäköisyys × vakavuus.

5. Riskinhallintatoimenpiteet

5.1 Tekniset suojat (R1, R2, R4)

• Pääsynvalvonta: Firebase Authentication + Firestore Rules. Pääsy tietoihin perustuu rooliin (admin, leiripomo, ryhmänjohtaja, EA-vastaava, keittiö, yövalvoja). Ryhmänjohtajalla pääsy vain oman ryhmän leiriläisiin.
• Token-pohjainen huoltajaportaali: parentToken on 48 merkkiä pitkä (24 random byteä hex-koodattuna) ja vanhentuu 6 kuukauden kuluttua leirin päättymisestä (jos campInfo.endDate puuttuu, fallback 12 kk luonnista). Token voidaan peruuttaa milloin tahansa.
• Salaus levossa ja siirrossa: Firestore + Storage käyttävät TLS 1.3 + AES-256.
• EXIF-strippaus: Valokuvista poistetaan EXIF-metatiedot (mm. GPS-sijainti) ennen tallennusta Sharp-kirjastolla.
• Anonymisointi AI-puolella: Anthropic Claude saa vain anonymisoidut syötteet — leiriläisten nimiä ei lähetetä.
• Origin-validation + persistent rate-limit: claudeProxy, aiAssistant, chatHelp, summarizeAllergies tarkistavat HTTP-pyynnön alkuperän ja käyttävät Firestore-pohjaista rate-limittiä joka kestää Cloud Functions cold startit.
• Rooliperustainen XSS-suoja: kaikki käyttäjän syöte renderöidään esc()-funktion läpi (ml. PDF-tulostus ja ilmoittautumislomake).
• Sentry-virheraportointi: ei sisällä henkilötietoja (PII-maski).
• Firestore PITR (Point-in-Time Recovery): 7 päivän palautusikkuna katastrofin varalta.
• Subcollection-arkkitehtuuri: leiriläisten henkilötiedot tallennettu camp-doc -alikokoelmaan (camps/{cid}/participants), johon Firestore Rules myöntää lukuoikeuden vain need-to-know-rooleille — ryhmänjohtaja näkee vain oman ryhmänsä lapset.
• Kovakoodatut field-allowlistit: guardian, guardianPhone, address, email -kenttiin pääsy vain campLeader+medic+admin (ohittaa custom-perms).
• Multi-role-tuki: servRoles + extraRoles unionoidaan automaattisesti — leader+medic-käyttäjä saa molempien roolien oikeudet.

5.2 Organisatoriset suojat (R3)

• Leirin järjestäjä on rekisterinpitäjä, Campflow tietojenkäsittelijä — vastuunjako on selvästi dokumentoitu (DPA-sopimus).
• Henkilökunta-roolit dokumentoitu sovelluksen ohjeissa (docs.html).
• Käyttöehdoissa kielto luovuttaa tunnuksia kolmansille.
• Pääsyn rajaus rooliperusteisesti Firestore Rules + client-allowlist; varsinainen lukutapahtuma-loki ei ole käytössä (perustelu: Firestore Rules estää väärinkäytön ennalta + audit_log-kokoelma kerää kirjoitustapahtumat ja vientipyynnöt).

5.3 Säilytysaikojen valvonta (R5)

• cleanupExpiredData-funktio ajaa joka yö klo 03:00 (Europe/Helsinki) ja poistaa automaattisesti porras-mallin mukaisesti.
• Toiminnasta kirjoitetaan system_log -merkintä, jota super-admin valvoo.
• Refaktoroitu collectionGroup-kyselyksi (poistaa N+1-ongelman ja parantaa luotettavuutta organisaatioiden määrän kasvaessa).
• Ehdoton enimmäissäilytys myös leireille joilla ei ole endDate:a: participantHistory/audit-jälki 24 kk, consentLog 36 kk, aiAudit 90 vrk merkinnän tekohetkestä. Erilliset collectionGroup-fieldOverride-indeksit varmistavat että poistokysely toteutuu eikä jää hiljaa indeksipuutteeseen.

5.4 Huoltajan oikeudet (R6) — itsepalvelu

• Art. 15 (oikeus tutustua): huoltajaportaalissa "Lataa kopio tiedoista (PDF / luettava muoto)" — käyttäjäystävällinen kooste lapsen kaikista tiedoista.
• Art. 17 (oikeus tulla unohdetuksi): "Pyydä tietojen poistoa" — pyyntö rekisteröidään, leirin järjestäjä saa sähköposti-ilmoituksen ja käsittelee 30 vrk:n sisällä.
• Art. 7(3) (suostumuksen peruutus): "Peruuta suostumus terveystietojen käsittelyyn" — yhtä helppoa kuin suostumuksen antaminen, milloin tahansa, ilman aikarajaa. Tyhjentää lapsen Art. 9 -kentät välittömästi, redaktoi aiemman participantHistory-erityistietosisällön muotoon "[withdrawn]", kirjaa consentLog-merkinnän (Art. 7(1) osoitusvelvollisuus) ja ilmoittaa rekisterinpitäjälle jäännösdatan viimeistelyä varten (Art. 17(1)(b)). Ei peruuta osallistumista.
• Art. 20 (siirto-oikeus): "Lataa raakadata (JSON, kehittäjille)" — koneluettava JSON, kelpaa siirtoon toiseen järjestelmään.
• Rate-limit: 5 latausta vuorokaudessa per token (riittää huoltajan käyttöön, estää tokenin vuotamisen tilanteessa massalataukset).
• Pyynnöt rekisteröidään audit_log-kokoelmaan.

5.5 Erityiset toimenpiteet alaikäisille

• Lapsi ei kirjaudu sovellukseen — kaikki tiedot kulkevat huoltajan tai järjestäjän kautta.
• Huoltajan suostumus on edellytys ilmoittautumiselle (lupalappu + nimenomainen terveystietosuostumus).
• 12-vuotias tai vanhempi voi antaa oman suostumuksensa kuvankäyttöön (lainsäädännöllinen ikäraja vaihtelee).
• Ryhmänjohtaja näkee vain ryhmälleen kuuluvat lapset, ei muita.
• Suomen tietosuojalain (1050/2018) §5 mukaan alle 13-vuotiaiden tieto vaatii huoltajan suostumuksen — Campflow vaatii kaikilta alle 18-vuotiailta lisäsuojan vuoksi.

5.6 Roolikohtaiset Art. 9 -kenttärajaukset

Allowlist on kovakoodattu sovelluskoodissa ja Firestore Rulesissa, ei voi ohittaa custom-perms:lla:

• Lääkitysväkymä (medications-tabi): vain campLeader, medic, admin.
• Ruokailu-tabi (food): vain campLeader, kitchen, kitchenHelper, admin.
• Palaute-tabi (feedback): vain campLeader, admin.
• Huoltajakentät (guardian, guardianPhone): vain campLeader, medic, night, admin.
• Osoite ja sähköposti (address, email): vain campLeader, medic, admin.
• Allergiat (allergies): oman ryhmän ohjaaja (need-to-know) + campLeader + medic + admin + kitchen + kitchenHelper (anafylaksia-riski tarjoilun yhteydessä).
• Erityisruokavaliot (dietaryNeeds): kuten allergiat — sis. kitchenHelper.
• Terveystiedot (health: krooniset sairaudet, lääkitykset): oman ryhmän ohjaaja + campLeader + medic + admin + kitchen. kitchenHelper EI näe näitä (Art. 5(1)(c) datan minimointi).
• kitchenBriefings (allergeenit nimitasolla): vain campLeader, kitchen, medic, admin. kitchenHelper EI näe (suostumus rajattu pää-keittiöhenkilöstölle).
• Bussinäkymä: ohjaaja näkee vain oman ryhmänsä lapset huoltajan yhteystiedoilla.
• PDF-tulostus: sama field-allowlist pakottaa rajauksen.

6. Konsultaatio rekisteröityjen kanssa

Huoltajat saavat ilmoittautumisen yhteydessä:

• Linkin tietosuojaselosteeseen (Art. 13/14 informointivelvollisuus).
• Erillisen suostumusrastin terveystietojen käsittelyyn (Art. 9(2)(a)).
• Erillisen suostumusrastin kuvanjulkaisuun.
• Tiedon kuluttajansuojalain peruutusoikeuden puuttumisesta (KSL 6:16§ kohta 12 — vapaa-ajan palvelu määrätyllä ajankohdalla).
• Tiedon maksuvelvoitteesta selkeästi vahvistuspainikkeessa (KSL 6:13§ — "Ilmoittaudu ja maksa X €").

6.1 Viivakoodiskannaus

Pääkokille tarjotaan tukku-tilanteissa viivakoodiskanneri (BarcodeDetector + Open Food Facts -tietokanta), joka näyttää tuotteen allergeenit + ravintotiedot ja vertaa niitä leirin osallistujien strukturoituihin allergeenitietoihin.

Tietovirta

• Lähetettävät tiedot kolmannelle osapuolelle: vain tuotteen GTIN-numero (8/12/13/14 numeroa). EI henkilötietoja, EI leirin tietoja, EI allergeenivertailun tuloksia.
• Allergeenivertailu: tehdään client-puolella selaimessa — leiriläisten p.allergens-data EI poistu Campflow-perimetristä.
• Audit-loki: users/{uid}/camps/{campId}/barcodeScans/{id} tallentaa staffin nimen, viivakoodin, tuotenimen ja allergeenit. Säilytys 2 vuotta (perustelu: elintarviketurvallisuuden jäljitettävyys, EU 852/2004 + Suomen elintarvikelaki 297/2021).

Riskinarviointi

R7 — Pääkokin tunnistetiedot OFF-palvelimella: Cloud Run lähettää OFF:lle User-Agent: Campflow - https://campflow.fi - info@campflow.fi + Cloud Run egress-IP:n. Tämä ei ole loppukäyttäjän henkilötieto, vaan Campflow-organisaation palvelinmerkintä. Lievä, ei vaadi DPA:ta.

R8 — OFF-data on vapaaehtoisten ylläpitämä: väärä tai vanhentunut allergeenitieto voi johtaa virheellisiin päätöksiin. Lievennys: UI-disclaimer "Tarkista aina pakkaus" + neutraali "ei osu listaan" -muotoilu joka ei anna positiivista turva-väitettä (EU 1169/2011 + vahingonkorvauslaki 412/1974).

R9 — Cache 30 päivää: jos OFF:ssa allergeeni lisätään tuotteelle, Campflow näyttää vanhaa tietoa max kuukauden. Lievennys: aina näkyvä disclaimer + Avaa OFF:ssa -linkki.

Lainmukainen peruste

Käsittely (audit-loki) perustuu GDPR Art. 6(1)(f) — oikeutettu intressi (rekisterinpitäjän intressi varmistaa elintarviketurvallisuus + jäljitettävyys, joka ylittää staff-henkilön intressin olla nimettömänä työajan kirjauksissa). Henkilötiedot rajattu staff-rooliin, ei leiriläisten tietoja audit-lokissa.

6.2 Keittiö-briefing

Pääkokin pysyvä muistio keittiön staffille (kitchen / campLeader / admin / medic). Sisältää: vapaamuotoisen otsikon ja viestin (max 2000 merkkiä), automaattisesti koostetun "vakavat allergiat"-listan (lapsen NIMI + EU14-allergeenit + vapaa lisäteksti), runOut/leftover-palautteen 3 päivän ajalta. Vaihtoehtoinen sähköpostilähetys ulkopuolisille vapaehtoisille.

Tietovirta

• Sisäinen käsittely: Firestore users/{uid}/camps/{campId}/kitchenBriefings/{id} — luetaan vain leirin keittiöstaffilta (ks. firestore.rules). Leader-rooli (ryhmänjohtaja) EI näe briefing-paneelia, koska sisältää Art. 9 -tietoja (vakavasti allergisten lasten nimet) ja huoltajan suostumus on rajattu "keittiölle ja terveysvastaaville".
• Sähköpostilähetys: Resend (USA/EU) → ulkopuolisen vapaaehtoisen sähköpostiin. Pääkokki kirjoittaa viestin ja valitsee opt-in "Lähetä myös sähköpostina". Modaali sisältää oranssin GDPR Art. 9 -varoituksen joka kehottaa ettei lapsen nimeä yhdistä terveystietoon vapaatekstissä.
• Säilytysaika: client suodattaa expiresAt-kentällä (max 30 pv käyttäjän valinnasta), cleanupExpiredData-CF poistaa Firestoresta 7 pv expiresAt-jälkeen kovasti.

Riskinarviointi

R10 — Vapaateksti houkuttelee Art. 9 -tietoja: käyttäjä voi kirjoittaa "Liisa allerginen pähkinöille, EpiPen autossa" body-kenttään. Lievennys: oranssi varoitus modaalin alussa (4 kieltä), placeholder "esim. Tiistain ruokalistalle lisättiin gluteeniton vaihtoehto. Tarkista pakkaukset.", auto-osio (yläosassa) hoitaa vakavat allergiat strukturoidusti.

R11 — Recipient-osoitteet sähköpostilähetyksessä: CF tallentaa lähetysstatuksen audit-lokiin system_log-kokoelmaan, mutta ei sähköpostiosoitteita kirkkaasti — vain määrät (recipientCount, sentCount). Tämä rajaa Art. 5(1)(c) datan minimointi-vaatimusta.

R12 — Phishing-vektori: aiemmin client lähetti title+body POSTissa, mikä mahdollisti spämmin Campflow-brändillä. Korjaus: CF lukee briefingin Firestoresta briefingId:llä — ei luota client-bodyyn.

Lainmukainen peruste

Sisäinen käsittely: GDPR Art. 6(1)(f) — oikeutettu intressi (elintarviketurvallisuus + henkilökunnan tiedonkulku). Sähköpostilähetys ulkopuoliselle: Art. 6(1)(a) — käyttäjän nimenomainen suostumus opt-in-checkbox:lla. Vakavasti allergisten lasten nimet auto-osiossa: Art. 9(2)(a) — huoltajan suostumus "terveystietojen jakamiseen leirin staffin kesken".

6.3 Datalaatu-mittari

Reseptin pisteytys 0-100 % perustuu: perusresepti (+30), ainesosien allergeenitiedot (+25), Fineli-linkitys (+25), määrät (+10), reseptin allergensInRecipe-lista (+10). Alle 60 % näytetään päivänäkymässä punainen varoitus jos leirillä on vakavasti allerginen henkilö (heuristiikka: p.allergiesNotes sisältää "vakava"/"anafylak"/"epipen").

Tietovirta

• Käsittely: ainoastaan client-puolella (food.js:n _calcRecipeQuality). Reseptin data tulee Firestoresta, ei siirretä eteenpäin.
• Päivänäkymän varoitus: näkyy keittiöstaffille kun aterialla on resepti jonka data-laatu on alle 60 % JA leirillä on Art. 9 -merkitty vakavasti allerginen lapsi. UI ei näytä lapsen nimeä tai allergeenia, vain "tarkista pakkaukset käsin"-tekstin.

Riskinarviointi

R13 — Päivänäkymän varoitus paljastaa että "leirillä on vakavasti allerginen henkilö": tämä on Art. 9 -tieto (terveys), vaikka nimeä ei näytetä. Sama keittiön rooli-rajoitus kuin briefing-paneelissa (kitchen/campLeader/admin/medic). Leader-rooli näkee päivänäkymän mutta ei tätä varoitusta erikseen — kuitenkin ateriakortti on samalla sivulla ja staff voi päättää itse mitä tarvitsee.

R14 — Heuristinen severity-tunnistus: regex matchaa "vakava|anafylak|epipen|severe|anaphyl" allergiesNotes-kentästä. False negativeja ja false positiveja mahdollisia. Tämä ei ole automaattinen päätöksenteko Art. 22 mielessä — pelkkä UI-vihje, päätös on aina kokin.

Lainmukainen peruste

Art. 6(1)(f) oikeutettu intressi: lapsen turvallisuus + elintarviketurvallisuuden jäljitettävyys. Datalaatu-laskenta on pelkästään client-puolella, ei tallennu Firestoreen — joten ei uusia tallennuskategorioita. Läpinäkyvyys (Art. 5(1)(a)): UI-tekstit ovat selkeitä ja käyttäjä näkee mitä lasketaan.

7. Päätelmä

Tunnistetut korkean tason riskit (R1, R2) on lievennetty kohtalaiselle tasolle teknisten suojien yhdistelmällä (pääsynvalvonta + rooliperustaisuus + token-vanheneminen + EXIF-strippaus + audit-loki). Kohtalaiset riskit (R3-R5) on lievennetty alhaiselle tasolle organisatoristen ja teknisten toimenpiteiden yhdistelmällä. Viivakoodiskannauksen riskit (R7-R9) ovat lieviä.

Jäännösriski on hyväksyttävällä tasolla. Erityistä konsultaatiota tietosuojavaltuutetun toimiston kanssa (Art. 36) ei katsota tarpeelliseksi, mutta tämä DPIA toimitetaan TSV:lle pyynnöstä.

DPIA tarkistetaan vuosittain tai aiemmin, jos käsittelytoimissa tapahtuu merkittäviä muutoksia (uusi tietoryhmä, uusi käsittelijä, uusi käsittelyperuste).

8. Yhteystiedot

Tämän DPIA:n laatija:

Esa Mäkinen · Campflow palveluntarjoaja · info@campflow.fi

Rekisterinpitäjien (organisaatioiden) yhteystiedot löytyvät kunkin organisaation omasta tietosuojaselosteesta.

Tietosuojavaltuutetun toimisto (valvontaviranomainen Suomessa): tietosuoja.fi

Campflow — Data Protection Impact Assessment (DPIA)

Assessment under GDPR (EU 2016/679) Art. 35. Concerns processing operations within the Campflow camp management service involving minors’ personal data and special categories of personal data (health, allergies, medication).

1. Was a DPIA required?

Yes. GDPR Art. 35(3) lists situations where a DPIA is mandatory. Campflow meets several criteria:

• Minors’ personal data (Art. 8) — most data subjects are camp participants under 16.
• Special categories of personal data (Art. 9) — health information, allergies and medication are core data in the system.
• Large scale — the service is used by multiple organisations with thousands of data subjects in total.
• Vulnerable group — minors cannot fully understand the consequences of their consent.

The list of processing operations requiring a DPIA published by the Finnish Data Protection Ombudsman (TSV 2018) supports this assessment.

2. Systematic description of the processing

2.1 Description of processing

Campflow is a browser-based camp management service (SaaS) used by parishes, scout groups, sports clubs and associations to manage camps for children and young people. Guardians register their children for camps, organisers receive registrations, collect required permissions, plan the programme and communicate with guardians during the camp.

2.2 Purposes of processing

• Receiving and managing camp registrations
• Ensuring participants’ health safety (allergies, medication, swimming ability)
• Planning groups, accommodation and schedules
• Communication with guardians (camp letter, guardian portal, emergency notifications)
• Fulfilling statutory obligations (bookkeeping, occupational safety, medication log)

2.3 Data processed

2.4 Data flow

1. The guardian fills the public registration form (ilmo.html) → data is written to Firestore.
2. The organiser logs into the app (app.html), sees registrations, approves/rejects, divides into groups.
3. Staff (camp leader, group leader, first-aid responsible, kitchen) get role-based limited access.
4. Guardian portal (huoltaja.html) — the guardian receives a parentToken link via email and can see their child’s situation during the camp.
5. Cloud Functions handle email (Resend), photo processing (Sharp + EXIF stripping) and AI features (Anthropic Claude).
6. After retention periods expire, data is automatically deleted according to the tiered model (cleanupExpiredData).

2.5 Recipients and processors

3. Assessment of necessity and proportionality

3.1 Legal basis

The primary basis is Art. 6(1)(b) contract (camp contract between guardian and organiser), and for health data Art. 9(2)(a) explicit consent, provided by the guardian on the registration form with a separate checkbox. The medication log is based on Art. 6(1)(c) statutory obligation (patient injury practice).

3.2 Data minimisation

• Only data necessary for camp activities is collected — no personal identity codes, school background or religious beliefs (except where a parish’s own activities are inherently religious in nature).
• By default, a group leader sees full data only for participants in their own group. Children from other groups appear anonymised (“John D.”) e.g. in the accommodation table.
• Push notifications do not show the child’s name or health data (lock screen protection).
• AI features (e.g. dining allergy analysis) receive only anonymised inputs — the Anthropic API does not see the child’s name.

3.3 Retention periods (tiered model)

4. Risk assessment

Risks have been assessed from the perspective of the data subjects using a three-step scale (low / moderate / high), evaluating likelihood × severity.

5. Risk mitigation measures

5.1 Technical safeguards (R1, R2, R4)

• Access control: Firebase Authentication + Firestore Rules. Data access is role-based (admin, camp leader, group leader, first-aid responsible, kitchen, night guard). A group leader only has access to participants in their own group.
• Token-based guardian portal: parentToken is 48 characters long (24 random bytes hex-encoded) and expires 6 months after the camp ends (if campInfo.endDate is missing, fallback 12 months from creation). The token can be revoked at any time.
• Encryption at rest and in transit: Firestore + Storage use TLS 1.3 + AES-256.
• EXIF stripping: EXIF metadata (incl. GPS location) is removed from photos before storage using the Sharp library.
• Anonymisation for AI: Anthropic Claude receives only anonymised inputs — participants’ names are not sent.
• Origin validation + persistent rate-limit: claudeProxy, aiAssistant, chatHelp, summarizeAllergies validate the origin of the HTTP request and use a Firestore-backed rate-limit that survives Cloud Functions cold starts.
• Role-based XSS protection: all user input is rendered through the esc() function (incl. PDF print and the registration form).
• Sentry error reporting: contains no personal data (PII mask).
• Firestore PITR (Point-in-Time Recovery): 7-day restore window for disaster recovery.
• Subcollection architecture: participants’ personal data is stored in a camp-doc subcollection (camps/{cid}/participants), to which Firestore Rules grant read access only to need-to-know roles — a group leader sees only their own group’s children.
• Hard-coded field allowlists: access to guardian, guardianPhone, address, email is restricted to campLeader+medic+admin (overrides custom permissions).
• Multi-role support: servRoles + extraRoles are automatically unioned — a leader+medic user receives the rights of both roles.

5.2 Organisational safeguards (R3)

• The camp organiser is the controller, Campflow is the processor — the division of responsibility is clearly documented (DPA agreement).
• Staff roles are documented in the service’s help pages (docs.html).
• The terms of service prohibit sharing credentials with third parties.
• Access is restricted on a role basis via Firestore Rules + client allowlist; an actual read-event log is not in use (rationale: Firestore Rules prevents misuse in advance + the audit_log collection records write events and export requests).

5.3 Retention period monitoring (R5)

• The cleanupExpiredData function runs every night at 03:00 (Europe/Helsinki) and automatically deletes according to the tiered model.
• Operations are written to a system_log entry monitored by a super-admin.
• Refactored as a collectionGroup query (removes the N+1 problem and improves reliability as the number of organisations grows).
• Absolute maximum retention also for camps without an endDate: participantHistory/audit trail 24 months, consentLog 36 months, aiAudit 90 days from the entry. Dedicated collectionGroup fieldOverride indexes ensure the deletion query actually executes and does not silently fail on a missing index.

5.4 Guardian rights (R6) — self-service

• Art. 15 (right of access): in the guardian portal “Download a copy of the data (PDF / readable format)” — a user-friendly summary of all the child’s data.
• Art. 17 (right to be forgotten): “Request data deletion” — the request is logged, the camp organiser receives an email notification and processes it within 30 days.
• Art. 7(3) (withdrawal of consent): “Withdraw consent to health data processing” — as easy as giving consent, at any time, with no time limit. Immediately clears the child’s Art. 9 fields, redacts the special-category content of prior participantHistory to “[withdrawn]”, writes a consentLog entry (Art. 7(1) accountability) and notifies the controller to complete erasure of any residual data (Art. 17(1)(b)). Does not cancel participation.
• Art. 20 (right to data portability): “Download raw data (JSON, for developers)” — machine-readable JSON, suitable for transfer to another system.
• Rate-limit: 5 downloads per day per token (sufficient for guardian use, prevents mass downloads in case of token leak).
• Requests are recorded in the audit_log collection.

5.5 Special measures for minors

• The child does not log into the application — all data flows through the guardian or organiser.
• Guardian consent is a prerequisite for registration (permission slip + explicit health data consent).
• A person aged 12 or older can give their own consent to photo use (the statutory age limit varies).
• A group leader only sees children belonging to their group, not others.
• Under Finnish Data Protection Act (1050/2018) §5, data on children under 13 requires guardian consent — Campflow requires it for all under 18 as an extra safeguard.

5.6 Role-specific Art. 9 field restrictions

The allowlist is hard-coded in the application code and in Firestore Rules; it cannot be bypassed via custom permissions:

• Medications tab: only campLeader, medic, admin.
• Food tab: only campLeader, kitchen, kitchenHelper, admin.
• Feedback tab: only campLeader, admin.
• Guardian fields (guardian, guardianPhone): only campLeader, medic, night, admin.
• Address and email: only campLeader, medic, admin.
• Allergies: own group leader (need-to-know) + campLeader + medic + admin + kitchen + kitchenHelper (anaphylaxis risk during serving).
• Special diets (dietaryNeeds): same as allergies — incl. kitchenHelper.
• Health data (health: chronic illnesses, medications): own group leader + campLeader + medic + admin + kitchen. kitchenHelper does NOT see these (Art. 5(1)(c) data minimisation).
• kitchenBriefings (allergens at name level): only campLeader, kitchen, medic, admin. kitchenHelper does NOT see (consent limited to main kitchen staff).
• Bus view: a leader sees only their own group’s children with guardian contacts.
• PDF print: the same field allowlist enforces the restriction.

6. Consultation with data subjects

Guardians receive, in connection with registration:

• A link to the privacy policy (Art. 13/14 information obligation).
• A separate consent checkbox for processing health data (Art. 9(2)(a)).
• A separate consent checkbox for photo publication.
• Information about the lack of a withdrawal right under the Finnish Consumer Protection Act (CPA 6:16§ item 12 — leisure-time service at a fixed point in time).
• Information about the payment obligation clearly on the confirmation button (CPA 6:13§ — “Register and pay X €”).

6.1 Barcode scanning

The head cook is offered a barcode scanner (BarcodeDetector + Open Food Facts database) for bulk situations, which displays the product’s allergens + nutritional info and compares them with the camp participants’ structured allergen data.

Data flow

• Data sent to third party: only the product’s GTIN number (8/12/13/14 digits). NO personal data, NO camp data, NO allergen comparison results.
• Allergen comparison: performed client-side in the browser — participants’ p.allergens data does NOT leave the Campflow perimeter.
• Audit log: users/{uid}/camps/{campId}/barcodeScans/{id} stores the staff member’s name, barcode, product name and allergens. Retention 2 years (rationale: food safety traceability, EU 852/2004 + Finnish Food Act 297/2021).

Risk assessment

R7 — Head cook identifiers on OFF server: Cloud Run sends OFF the User-Agent: Campflow - https://campflow.fi - info@campflow.fi + the Cloud Run egress IP. This is not end-user personal data but a Campflow organisational server marker. Mild, does not require a DPA.

R8 — OFF data is maintained by volunteers: incorrect or outdated allergen information may lead to incorrect decisions. Mitigation: UI disclaimer “Always check the packaging” + neutral “does not match the list” wording that does not give a positive safety claim (EU 1169/2011 + Finnish Tort Liability Act 412/1974).

R9 — 30-day cache: if an allergen is added to a product in OFF, Campflow shows outdated information for up to a month. Mitigation: always-visible disclaimer + “Open in OFF” link.

Legal basis

Processing (audit log) is based on GDPR Art. 6(1)(f) — legitimate interest (the controller’s interest in ensuring food safety + traceability, which overrides the staff member’s interest in remaining anonymous in working-time entries). Personal data is limited to the staff role, no participant data in the audit log.

6.2 Kitchen briefing

A permanent note from the head cook to the kitchen staff (kitchen / campLeader / admin / medic). Includes: a free-form title and message (max 2000 characters), an automatically compiled “severe allergies” list (child’s NAME + EU14 allergens + free additional text), runOut/leftover feedback from the past 3 days. Optional email delivery to external volunteers.

Data flow

• Internal processing: Firestore users/{uid}/camps/{campId}/kitchenBriefings/{id} — read only by the camp’s kitchen staff (see firestore.rules). The leader role (group leader) does NOT see the briefing panel because it contains Art. 9 data (names of children with serious allergies) and guardian consent is limited to “kitchen and health responsible”.
• Email delivery: Resend (USA/EU) → external volunteer’s email. The head cook writes the message and opts in to “Also send by email”. The modal contains an orange GDPR Art. 9 warning that urges not to associate a child’s name with health data in free text.
• Retention period: the client filters by expiresAt (max 30 days from user choice), the cleanupExpiredData CF removes from Firestore 7 days after expiresAt hard.

Risk assessment

R10 — Free text invites Art. 9 data: a user may write “Liisa allergic to nuts, EpiPen in the car” in the body field. Mitigation: orange warning at the top of the modal (4 languages), placeholder “e.g. A gluten-free option was added to Tuesday’s menu. Check the packaging.”, the auto section (at the top) handles severe allergies in structured form.

R11 — Recipient addresses in email delivery: the CF stores delivery status in the audit log system_log collection, but not email addresses in clear text — only counts (recipientCount, sentCount). This restricts the Art. 5(1)(c) data minimisation requirement.

R12 — Phishing vector: previously the client sent title+body in the POST, which made spam in the Campflow brand possible. Fix: the CF reads the briefing from Firestore by briefingId — it does not trust the client body.

Legal basis

Internal processing: GDPR Art. 6(1)(f) — legitimate interest (food safety + staff information flow). Email delivery to an outsider: Art. 6(1)(a) — the user’s explicit consent via opt-in checkbox. Names of children with serious allergies in the auto section: Art. 9(2)(a) — guardian consent to “share health data among the camp staff”.

6.3 Data quality meter

Recipe scoring 0–100 % is based on: base recipe (+30), ingredient allergen information (+25), Fineli linkage (+25), quantities (+10), the recipe’s allergensInRecipe list (+10). Below 60 %, the day view shows a red warning if the camp has a person with severe allergies (heuristic: p.allergiesNotes contains “vakava”/“anafylak”/“epipen”).

Data flow

• Processing: only client-side (food.js’s _calcRecipeQuality). Recipe data comes from Firestore, is not transferred onwards.
• Day view warning: visible to the kitchen staff when a meal has a recipe whose data quality is below 60 % AND the camp has a child marked Art. 9 as severely allergic. The UI does not show the child’s name or the allergen, only “check the packaging by hand”.

Risk assessment

R13 — The day view warning reveals that “the camp has a person with serious allergies”: this is Art. 9 data (health), even though the name is not shown. Same role restriction as in the briefing panel (kitchen/campLeader/admin/medic). The leader role sees the day view but not this warning separately — however, the meal card is on the same page and the staff can decide for themselves what they need.

R14 — Heuristic severity detection: the regex matches “vakava|anafylak|epipen|severe|anaphyl” in the allergiesNotes field. False negatives and false positives are possible. This is not automated decision-making within the meaning of Art. 22 — merely a UI hint, the decision is always the cook’s.

Legal basis

Art. 6(1)(f) legitimate interest: child safety + food safety traceability. The data quality calculation is purely client-side and is not stored in Firestore — so no new storage categories. Transparency (Art. 5(1)(a)): the UI texts are clear and the user sees what is being calculated.

7. Conclusion

The identified high-level risks (R1, R2) have been mitigated to a moderate level through a combination of technical safeguards (access control + role basis + token expiry + EXIF stripping + audit log). The moderate risks (R3–R5) have been mitigated to a low level through a combination of organisational and technical measures. The risks for barcode scanning (R7–R9) are mild.

The residual risk is at an acceptable level. Prior consultation with the Data Protection Ombudsman (Art. 36) is not deemed necessary, but this DPIA will be provided to the Ombudsman upon request.

The DPIA is reviewed annually or earlier if significant changes occur in the processing operations (new data category, new processor, new legal basis).

8. Contact information

Author of this DPIA:

Esa Mäkinen · Campflow service provider · info@campflow.fi

Contact details of the controllers (organisations) can be found in each organisation’s own privacy policy.

Office of the Data Protection Ombudsman (supervisory authority in Finland): tietosuoja.fi

Campflow — Konsekvensbedömning avseende dataskydd (DPIA)

Bedömning enligt GDPR (EU 2016/679) Art. 35. Avser behandling av personuppgifter inom Campflow lägeradministrationstjänst som rör minderårigas personuppgifter och särskilda kategorier av personuppgifter (hälsa, allergier, medicinering).

Obs

Den fullständiga bedömningen finns på finska, eftersom den primärt riktar sig till finska Dataombudsmannens byrå (Tietosuojavaltuutetun toimisto). Denna svenska sammanfattning täcker de viktigaste slutsatserna.

1. DPIA krävs

Ja — Campflow behandlar minderårigas personuppgifter (Art. 8) och särskilda kategorier (Art. 9: hälsa, allergier, medicinering) i stor skala och berör en sårbar grupp.

2. Riskminimering

• Rollbaserad åtkomstkontroll via Firebase Rules
• parentToken upphör att gälla efter 6 månader och kan återkallas
• EXIF-data avlägsnas före lagring
• Anonymisering före AI-tjänster
• Stegvis automatisk radering (6 mån / 12 mån / 2 år)
• Självbetjäning av GDPR-rättigheter (Art. 15/17/20) i vårdnadshavarportalen

3. Slutsats

Höga risker har minskats till måttlig nivå genom kombinerade tekniska och organisatoriska åtgärder. Restrisken är acceptabel.

Campflow — Personvernkonsekvensvurdering (DPIA)

Vurdering i henhold til GDPR (EU 2016/679) Art. 35. Gjelder behandling av personopplysninger i Campflow leiradministrasjon som omhandler mindreåriges personopplysninger og særlige kategorier av personopplysninger (helse, allergier, medisinering).

Merk

Den fullstendige vurderingen er tilgjengelig på finsk, ettersom den primært er rettet til det finske Datatilsynet (Tietosuojavaltuutetun toimisto). Dette norske sammendraget dekker de viktigste konklusjonene.

1. DPIA påkrevd

Ja — Campflow behandler mindreåriges personopplysninger (Art. 8) og særlige kategorier (Art. 9: helse, allergier, medisinering) i stor skala og berører en sårbar gruppe.

2. Risikoreduksjon

• Rollebasert tilgangskontroll via Firebase Rules
• parentToken utløper etter 6 måneder og kan tilbakekalles
• EXIF-data fjernes før lagring
• Anonymisering før AI-tjenester
• Trinnvis automatisk sletting (6 mnd / 12 mnd / 2 år)
• Selvbetjening av GDPR-rettigheter (Art. 15/17/20) i foresattportalen

3. Konklusjon

Høye risikoer er redusert til moderat nivå gjennom kombinerte tekniske og organisatoriske tiltak. Restrisikoen er akseptabel.