Senast uppdaterad: 2026-06-12
Denna sida riktar sig särskilt till kommunala upphandlare och dataskyddsombud som behöver granska Skolkolls databehandling inför avtal. För en allmän översikt, se integritetspolicyn. För personuppgiftsbiträdesavtal (PuB), se PuB-mall.
1. Roller och kontakt
För personuppgifter som omfattas av kommunlicens-avtalet är kommunen personuppgiftsansvarig och Skolkoll personuppgiftsbiträde. För personuppgifter som Skolkoll behandlar för egen räkning (t.ex. besökare på skolkoll.se utan inloggning) är Skolkoll personuppgiftsansvarig — se integritetspolicyn.
Personuppgiftsbiträde (Skolkoll): Agilenge AB
Organisationsnummer: 559220-2088
Kontakt för dataskyddsfrågor: markus@skolkoll.se
Skolkoll har inte utsett dataskyddsombud (DPO) eftersom verksamheten inte uppfyller kriterierna i GDPR art. 37 (kärnverksamheten är inte storskalig övervakning av personuppgifter; inga särskilda kategorier av personuppgifter behandlas systematiskt).
2. Underbiträden (subprocessors)
Skolkoll använder följande tredjepartstjänster för att tillhandahålla tjänsten. Tjänsterna omfattas av egna PuB-/DPA-avtal som överensstämmer med GDPR. Inloggningsleverantörerna för social inloggning behandlar autentiseringsuppgifter enligt sina egna villkor och EU:s standardavtalsklausuler (SCC).
| Leverantör | Tjänst | Datakategori | Region | DPA |
|---|---|---|---|---|
| Google Cloud (Firebase) | Hosting, Firestore, Cloud Functions, Cloud Storage, Authentication | Användarkonton, organisationsdata, analyticsEvents, faktureringshistorik | Cloud Functions, Hosting, Cloud Storage och Firestore: europe-west1 (Belgien). Firebase Authentication omfattas av Google Cloud DPA/SCC/DPF utan separat europe-west1-påstående här. | Google Cloud DPA (SCC inkluderat) |
| Stripe Payments Europe Ltd | Betalningshantering (kort + faktura) | Faktureringsadress, e-post, organisationsnummer, betalningsmetadata. Kortuppgifter passerar aldrig Skolkolls servrar. | Irland (EU) primärt; vissa fraud-detection-funktioner kan involvera Stripe US under SCC. | Stripe DPA |
| Resend Inc. | Transaktionella e-postutskick (kontobekräftelse, bevakningsmail, bevakningssammandrag, fakturor och säkerhetsvarningar) | E-postadress, namn, ämnesrad, e-postinnehåll (raderas efter 30 dagar hos Resend) | EU/US (Resends EU-region används där tillgängligt; SCC vid US-överföring) | Resend DPA |
| Functional Software, Inc. (Sentry) | Felövervakning av frontend och Cloud Functions | Felmeddelanden och stacktrace, webbläsare, OS, IP-adress (anonymiseras kort efter mottagandet av Sentry). I undantagsfall kan en stacktrace innehålla formulärdata som var aktiv när felet inträffade. | EU (Tyskland, ingest.de.sentry.io); SCC vid eventuell support från USA-team | Sentry DPA |
| Zoho Corporation / Zoho PageSense | Webbanalys, A/B-testning, heatmaps/session recording på publika sidor efter samtycke | Sidvisningar, klick/scroll, heatmap- och sessionsinspelning, experimentvariant, enhets- och webbläsarinfo. PageSense aktiveras inte på noindex-/konto-/admin-sidor och laddas först efter analytics-samtycke. | EU-script via cdn-eu.pagesense.io; Zoho DPA/SCC vid eventuell överföring utanför EU/EES | Zoho GDPR/DPA |
| Zoho Corporation / Zoho Desk | Kundsupportärenden för betalande kunder via support@skolkoll.se och supportportalen | Namn, e-postadress, organisationstillhörighet, ärendeinnehåll, ärendehistorik och tekniska bilagor som kunden frivilligt skickar in. | EU (supportportalen support.skolkoll.se pekar mot Zohos EU-hosting, zohohost.eu); Zoho DPA/SCC vid eventuell överföring utanför EU/EES | Zoho GDPR/DPA |
| Anthropic / OpenAI | AI-chatten "Kollen", AI-baserad skolbildsmoderering och skolbildsstilisering (endast efter samtycke) | Chatmeddelanden + skolkontext, samt uppladdade skolbildsbidrag som ska säkerhets-/innehållsgranskas eller omvandlas till chalkboard-illustration. För skolbild skickas bildfilen till OpenAI; kontaktuppgifter, fotografnamn, rättighetsinnehavare och fri text i formuläret skickas inte till AI-leverantören. AI-chattförfrågningar är "no-store"-flaggade där API tillåter (Anthropic: opt-out from training är default). | US (Anthropic) eller EU/US (OpenAI) — under SCC | Anthropic DPA · OpenAI DPA. Endast aktivt när användaren givit samtycke i chattfönstret eller skolbildsformuläret. |
| Identitetsleverantörer (Google, Microsoft, GitHub, Facebook, Apple) | Social inloggning (OAuth/OIDC) — endast om användaren väljer denna inloggningsmetod i stället för e-post/lösenord | Namn och e-postadress från vald leverantör vid inloggning | US (samtliga) — under SCC | Respektive leverantörs DPA/villkor; överföring till USA under EU:s standardavtalsklausuler (SCC) |
AI-behandling av skolbilder
När du lämnar skolbildsformuläret krävs separat samtycke innan bilden får behandlas av OpenAI för säkerhets-/innehållsgranskning och AI-baserad chalkboard-stilisering. Bildfilen kan skickas till OpenAI, men kontaktuppgifter, fotografnamn, rättighetsinnehavare och fri text i formuläret skickas inte till OpenAI. De uppgifterna lagras i Skolkolls Firestore för redaktionell granskning, attribution, rättighetsspårning och eventuell tvist.
För kommunlicens-data (användarkonton, organisationsdata, faktureringshistorik) anlitar vi inga reklamnätverk, marknadsföringsplattformar eller sociala media-pixlar. Webbanalys via Google Analytics 4 och Zoho PageSense körs endast efter explicit cookiesamtycke från besökare på publika, indexerbara sidor — se integritetspolicyn för detaljer. För inloggade kommun-användare körs ingen GA4- eller PageSense-spårning oavsett samtycke. Intern användningsstatistik sker via vår egen anonyma kollektor i Firebase utan persondata.
Anmälan om byte av underbiträde
När en kommunlicens är aktiv meddelar vi planerat byte eller tillägg av underbiträde via e-post till avtalad kontaktperson, DPO och organisationens administratörer minst 30 dagar innan ändringen genomförs. Kommunen har under den perioden rätt att invända — invändning hanteras enligt Kommunlicens-avtalets uppsägningsklausul. Vi använder inte det nya underbiträdet för kommunens personuppgifter innan invändningen har hanterats eller uppsägningstiden löpt ut.
3. Lagringstider per datakategori
Tider gäller från senaste händelse (t.ex. senaste inloggning, senaste betalning). Efter listad tid raderas eller anonymiseras data.
| Datakategori | Firestore-kollektion | Lagringstid | Laglig grund |
|---|---|---|---|
| Användarkonton (profil, medlemskap) | users, organizations/{id}/members | Tills kontot raderas av användaren. Inaktiva konton (24 mån utan inloggning) påminns och raderas efter 36 mån totalt. | Avtal (art. 6.1.b) |
| Organisationer + Pro-prenumerationer | organizations, organizations/{id}/subscriptions | Aktiv så länge prenumeration finns. Faktureringshistorik bevaras 7 år (bokföringslagen). | Rättslig förpliktelse (art. 6.1.c) för bokföring |
| Analytics events (rådata) | analyticsEvents | 90 dagar, sedan raderas individuella event. Aggregerade dygnssummor (utan persondata) bevaras indefinitivt. | Berättigat intresse (art. 6.1.f) — produktutveckling. Inga persondata lagras (sessionId är slumpmässigt, ingen IP, ingen user-agent). |
| Mail-kontakter och kampanjlistor | mailContacts, mailLists, campaigns | Tills avregistrering. Avregistrerade kontakter behåller anonymiserat hash av e-post (för att förhindra återupptagning) i 24 månader, sedan raderas helt. | Samtycke (art. 6.1.a) för nyhetsbrev; avtal (art. 6.1.b) för transaktionella mail. |
| Granskningslogg (audit log) | auditLog | 2 år. Varje ny post skrivs med expiresAt = nu + 2 år och raderas av Firestore TTL när TTL-policy för auditLog.expiresAt är aktiv. TTL-radering är asynkron efter att tiden passerat. | Berättigat intresse (art. 6.1.f) — säkerhet, spårbarhet, behörighetskontroll och tvist-/incidentutredning. |
| API-användningskvot | apiQuota/{orgId}/months/{YYYY-MM} | 13 månader (för faktureringskontroll och dispyt). | Rättslig förpliktelse (art. 6.1.c) |
| Bevakningar | watchers, watcherEvents | Aktiva bevakningar lagras tills användaren avslutar dem eller raderar kontot. Väntande bekräftelser har 48 timmars tokenfönster och rensas av cleanup-flödet. Bevakningshändelser i watcherEvents rensas löpande av digestjobbet, normalt efter högst 35 dagar. | Samtycke (art. 6.1.a) för anonym dubbel opt-in; avtal (art. 6.1.b) för inloggade kontofunktioner. |
| Skolbildsbidrag och rättighetsuppgifter | schoolImageSubmissions | Väntande bidrag bevaras tills redaktionell granskning är klar. Avvisade bidrag raderas efter 90 dagar via cleanup-flödet. Godkända bidrag och tillhörande rättighetsuppgifter bevaras så länge bilden används som käll-/provenance-underlag för publicerad skolbild, eller tills radering/avpublicering begärs och kan genomföras utan att bryta rättighetsspårning. | Uppladdning och AI-behandling: samtycke (art. 6.1.a). Attribution, rättighetsspårning och eventuell tvist efter granskning/publicering: berättigat intresse (art. 6.1.f). Fält kan omfatta photographerName, rightsHolderName, contactEmail, contactPhone, schoolName, kommentar och bildfil. |
| Raderingsbevis för avvisade skolbilder | imageCleanupAudit | 7 år från cleanup-tillfället. Varje post skrivs med expiresAt = deletedAt + 7 år och raderas via Firestore TTL när TTL-policy för imageCleanupAudit.expiresAt är aktiv. Posten innehåller endast submissionId, cutoff-datum, raderingsorsak, raderingstid och eventuell HMAC-SHA-256-hash av kontaktmejl — inte rå kontaktdata, bildfil, skolnamn eller fritext. | Berättigat intresse (art. 6.1.f) och ansvarsskyldighet enligt GDPR art. 5.2 — kunna svara på om en tidigare raderad bildsubmission har behandlats utan att behålla rå persondata. |
| AI-chattkonversation | Endast i webbläsarens sessionStorage — aldrig på vår server. | Raderas när webbläsarfliken stängs. | Samtycke (art. 6.1.a) |
| AI-granskningslogg | ai-audit-log | Varje post skrivs med expiresAt = nu + 90 dagar. Radering sker via Firestore TTL när TTL-policy på expiresAt är aktiv; TTL-radering är asynkron efter att tiden passerat och kan inte garanteras exakt dag 90. Operativ releaseverifiering: gcloud firestore fields ttls list ska visa aktiv TTL-policy för ai-audit-log.expiresAt. | Samtycke (art. 6.1.a) och berättigat intresse (art. 6.1.f) — missbruks- och säkerhetsspårning. |
4. Rätt till radering — operationellt flöde
Du kan utöva rätten till radering (GDPR art. 17) på följande sätt, sorterat från snabbast till mest manuellt:
AI-granskningslogg — TTL och manuell radering
AI-chatten sparar inte frågor eller svar permanent på Skolkolls server. För missbruks- och säkerhetsspårning skriver servern däremot en pseudonymiserad granskningspost i Firestore-kollektionen ai-audit-log för varje AI-anrop. Posten innehåller typ av anrop, SHA-256-hash av IP-adressen kortad till 16 tecken, skolkontext (max 50 tecken), längd på fråga och svar, status, timestamp och expiresAt.
Normal retention är 90 dagar: varje post sätts vid skrivning till expiresAt = nu + 90 dagar. Firestores TTL-mekanism raderar posten asynkront efter expiresAt när TTL-policyn för ai-audit-log.expiresAt är aktiv. TTL är inte en exakt raderingstidpunkt; raderingen kan ske en tid efter att fältets tid har passerat.
Vid begäran om tidigare radering kontaktar du info@skolkoll.se med ungefärlig tidpunkt och eventuell skolkontext för AI-anropet. Vi söker då server-side efter matchande poster och raderar identifierbara träffar manuellt med Admin SDK. Om en post inte kan matchas utan att samla in mer uppgifter ligger den kvar tills TTL-retentionen löper ut.
Skolbildsbidrag — avpublicering och radering
Om du har skickat in en skolbild kan du begära avpublicering, radering eller korrigering av fotograf-/rättighetsuppgifter via info@skolkoll.se. Ange skola, ungefärlig uppladdningstid och den e-postadress som användes i formuläret. Avvisade bidrag raderas automatiskt efter 90 dagar. Cleanup-flödet lämnar ett minimalt raderingsbevis i imageCleanupAudit så att vi kan svara på om bidraget har behandlats även efter att rådata har raderats. För godkända/publicerade bidrag gör vi en manuell rättighetskontroll innan radering, eftersom attribution och rättighetsspårning kan behöva bevaras för att hantera licens- eller tvistfrågor.
Självservice — användarkonto
- Logga in på Skolkoll-portalen.
- Gå till Kontoinställningar.
- Klicka på Radera konto. Bekräfta i dialogen.
- Kontot, dina medlemskap, dina bevakningar och din profilinformation raderas omedelbart från databasen.
Vad raderas inte automatiskt: Faktureringshistorik bevaras 7 år enligt bokföringslagen. Granskningsloggposter (auditLog) taggas med expiresAt för 2 års retention och raderas asynkront av Firestores TTL-mekanism när policyn är aktiv. Aggregerad analyticsdata innehåller redan inga personuppgifter och påverkas inte.
Begäran om radering — kommunlicens-administratör
Som kommunadministratör kan du begära radering av en specifik anställd från organisationen via support@skolkoll.se. Vi bekräftar mottagandet inom 1 arbetsdag och utför raderingen inom 14 dagar (GDPR-kravet är 30 dagar).
Begäran om radering — extern person (rektor som invänder)
Om du är namngiven rektor och invänder mot att ditt namn visas: skicka e-post till info@skolkoll.se med skolans skolenhetskod. Vi tar bort din uppgift från visningen inom 14 dagar och uppdaterar vår synkroniseringsfilter så att uppgiften inte återkommer även om Skolverket fortsätter att publicera den.
5. DPIA-light — riskbedömning för kommunlicens
För kommunlicens-kunder har vi gjort en förenklad konsekvensbedömning (DPIA-light) enligt GDPR art. 35. En fullständig DPIA är inte obligatorisk eftersom behandlingen inte uppfyller höga risk-kriterier (ingen storskalig övervakning, inga särskilda kategorier, ingen automatiserad beslutsfattande som påverkar individer).
Identifierade risker och åtgärder
| Risk | Sannolikhet × Konsekvens | Åtgärd |
|---|---|---|
| Otillbörlig åtkomst till organisationsdata | Låg × Medel | Firebase Auth med MFA-stöd; admin-rollkontroll på serversidan; auditLog för alla admin-åtgärder. |
| Datalek via tredjepartstjänst (Firebase, Stripe, Resend) | Låg × Hög | Endast EU-regioner där möjligt; SCC vid US-överföring; principen om minsta dataset (Stripe ser inga skoldata, Resend ser endast e-postadress + ämne). |
| Felaktig publicering av rektors namn | Medel × Låg | Källan är Skolverkets öppna API; rätt att invända via e-post med 14-dagars-respons; manuell synkroniseringsfilter applicerar invändningar permanent. |
| Sårbarhet i öppna analytics-endpoint | Låg × Låg | Origin-allowlist, distribuerad rate-limiting och event-storlekstak. Inga personuppgifter samlas i analytics. |
| Driftincident — scheduled function-fel utan upptäckt | Medel × Låg | Error-alerting wrapper skickar e-post till ops vid varje schedulerad funktions-fel. Manuell backfill-endpoint finns för kritiska syncs. |
6. Personuppgiftsincident
Vid misstänkt personuppgiftsincident:
- Skolkoll meddelar drabbade kommunlicens-administratörer och Personuppgiftsansvarigs avtalade kontakt, om denna är separat, med preliminär avisering inom 24 timmar via e-post och lämnar därefter löpande kompletteringar.
- Anmälan till Integritetsskyddsmyndigheten (IMY) sker inom 72 timmar om incidenten innebär risk för enskildas rättigheter.
- Incident-runbook och postmortem-process beskrivs i kommunlicens-avtalets bilaga ("IR-runbook").
7. Internationell dataöverföring
Personuppgifter behandlas i följande regioner:
- EU/EES: Firestore, Cloud Functions, Hosting och Cloud Storage via Firebase i
europe-west1(Belgien); Stripe-betalningar primärt i Irland. - USA/tredjeland: Firebase Authentication kan medföra Google-behandling utanför EU/EES. Sentry-support från USA-team, vissa Resend-överföringar, Anthropic/OpenAI-anrop (endast vid samtycke) samt social-login-leverantörer kan också medföra US-behandling.
För all US-överföring tillämpas följande rättsliga mekanismer:
- Standard Contractual Clauses (SCC) — Google/Firebase Authentication, Stripe, Resend, Anthropic, OpenAI samt identitetsleverantörerna för social inloggning (Google, Microsoft, GitHub, Facebook, Apple) omfattas av SCC enligt EU-kommissionens beslut 2021/914 när behandling sker utanför EU/EES.
- EU-US Data Privacy Framework (DPF) — alternativ rättslig grund för leverantörer som är DPF-certifierade (Google, Stripe).
Schrems II-konsekvenser: Skolkoll har gjort en Transfer Impact Assessment (TIA) per leverantör. Sammanfattning tillgänglig vid förfrågan från kommunlicens-kunder.
8. Tekniska och organisatoriska säkerhetsåtgärder
- Kryptering i transit: TLS 1.2+ för all kommunikation; HSTS aktiverat.
- Kryptering i vila: Firestore krypterar all data automatiskt med Google-managed keys.
- Åtkomstkontroll: Roll-baserad access (admin/användare); admin-token konstant-jämförelse via timing-safe-equal; auditLog för alla admin-API-anrop.
- Hemligheter: Alla API-nycklar och tokens lagras i Google Secret Manager och tillhandahålls säkert till runtime via Firebase Functions secrets-bindning. De finns inte i källkod eller commitas till repot.
- Rate limiting: Distribuerad Firestore-baserad rate limiter på alla publika endpoints; analytics-pipeline härdad mot abuse via origin-allowlist och event-storlekstak.
- Validering: Strikt schema-validering på alla user-inputs; field-level length caps; metadata-typkontroll inklusive array-element-validering.
- Övervakning: Cloud Logging för alla functions; error-alerting via Resend till ops-distribuerad lista vid scheduled function-fel; planerad Cloud Monitoring policy för error-rate.
- Backup: Firestore är konfigurerad för Point-in-Time Recovery (PITR) via Google Cloud, vilket ger tidpunktsåterställning inom det fönster som Firestore PITR tillhandahåller (upp till 7 dagar). Exakt PITR-status och eventuella schemalagda backup-exporter verifieras med
gcloud firestore databases describerespektivegcloud firestore backups schedules listföre varje release. Återställning har inte testats i ett kontrollerat disaster-recovery-tillfälle — vi avser att genomföra en sådan test inför första kommunlicens-produktionsdriftsättning.
9. Dokument för kommunal upphandling
- PuB-mall (personuppgiftsbiträdesavtal) — baserad på SKR:s standardavtal.
- Service Level Agreement (SLA) — upptidsåtaganden, supportresponstider, eskaleringsväg och kompensationspolicy.
- ROPA-sammanfattning (Records of Processing Activities) — publik sammanfattning av behandlingsförteckningen per GDPR art. 30. Fullständigt utdrag på begäran från kommunlicens-kunder.
- IR-runbook — incidenthanteringsprocess och kontaktuppgifter, levereras som bilaga till Kommunlicens-avtalet.
- Säkerhetsbilaga — dokumenterar release-grind för produktion, stage/prod-isolering, byggintegritet och säkerhetsheaders; levereras som bilaga till upphandlingssvar (utkast under juridisk granskning).
10. Klagomål
Om du anser att vi behandlar dina personuppgifter felaktigt har du rätt att lämna klagomål till tillsynsmyndigheten:
Integritetsskyddsmyndigheten (IMY)
Webbplats: imy.se
E-post: imy@imy.se
Telefon: 08-657 61 00