Senast uppdaterad: 2026-07-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): Skolspegeln AB
Organisationsnummer: 559359-7288
Kontakt för dataskyddsfrågor: dataskydd@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 via support@skolkoll.se/supportportalen samt journalistiska databeställningar när Zoho-intaget är godkänt och aktiverat | Namn, e-postadress, organisationstillhörighet eller redaktion/outlet, ärende-/beställningsinnehåll, ärendehistorik, interna triage-taggar, privat kvalitets-/neutralitetskommentar med riskklass/flaggor och tekniska bilagor som kunden eller journalisten 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 |
| Zoho Corporation / Zoho CRM | CRM-kontakt för journalistiska databeställningar, endast server-side efter godkänd Zoho-intake | Minimal relationsmetadata: namn, e-postadress, redaktion/outlet, bevakningsområde, källa och beställningsstatus. Används inte för kampanj-/nyhetsbrevsutskick utan separat samtycke och proveniens. | EU API via www.zohoapis.eu; Zoho DPA/SCC vid eventuell överföring utanför EU/EES | Zoho GDPR/DPA |
| Anthropic / OpenAI | AI-chatten "Kollen" och AI-baserad skolbildsstilisering (båda endast efter samtycke), samt två interna behandlingar utan samtyckeskrav: dokumentextraktion (Lane-D) och utkast till svar på journalistmail. Se "Internt AI-stöd" nedan. | Chatmeddelanden + skolkontext, samt uppladdade skolbildsbidrag som omvandlas till chalkboard-illustration. Bilden behandlas då enligt OpenAI:s egna säkerhets- och innehållspolicy; den redaktionella granskningen och godkännandet före publicering görs av en människa. För skolbild skickas bildfilen till OpenAI; kontaktuppgifter, fotografnamn, rättighetsinnehavare och fri text i formuläret skickas inte till AI-leverantören. De interna behandlingarna Lane-D-dokumentextraktion (OpenAI) och journalistmail-utkast (Anthropic) behandlar ytterligare datakategorier — se "Internt AI-stöd" nedan för dataflöde och laglig grund. AI-chatt- och Lane-D-förfrågningar skickas med lagring avstängd (no-store) där API tillåter (Anthropic: opt-out from training är default). | US (Anthropic och OpenAI) — under SCC | Anthropic DPA · OpenAI DPA |
| 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 skickas till OpenAI för AI-baserad chalkboard-stilisering. Bilden behandlas då enligt OpenAI:s egna säkerhets- och innehållspolicy. Den innehållsmässiga granskningen och godkännandet av bilden före publicering görs av en människa i redaktionen — Skolkoll kör inget separat AI-modereringssteg. 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.
Internt AI-stöd
Utöver den användarvända AI:n ("Kollen"-chatten och skolbildsstiliseringen, som båda kräver samtycke) använder Skolkoll AI i två interna behandlingar. Ingen av dem publiceras eller skickas automatiskt — en människa granskar och beslutar först. Laglig grund för båda är berättigat intresse (art. 6.1.f), inte samtycke.
Dokumentextraktion (Lane-D, OpenAI). För att sammanställa uppgifter ur offentliga handlingar (allmän handling) — i första hand statistik om kränkande behandling — skickas dokumentens råtext till OpenAI (gpt-4o-mini) för strukturerad extraktion. Eftersom det är råtext ur allmän handling kan en handling innehålla elevuppgifter, och den texten kan då passera OpenAI. Maskering av personuppgifter tillämpas på det som Skolkoll sparar efter extraktionen, inte på det som skickas till OpenAI. Anropen görs med lagring avstängd (no-store) och ingen extraherad uppgift publiceras automatiskt: alla kandidater går till en människogranskad kö och auto-publicering är avstängd.
Utkast till journalistsvar (Anthropic). Inkommande journalistmail (avsändarens namn, e-post, redaktion och meddelandetext) skickas till Anthropic (Claude) för att klassificera frågan och föreslå ett svarsutkast. En människa granskar och skickar; inget svar skickas automatiskt. Anthropic tränar inte på API-innehåll som standard. Uppgifterna används inte för utskick, kampanjer eller CRM utan separat samtycke och proveniens.
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). |
| Widget-beacon och missbruksspårning | widgetAbuseLog | Endast avvikande eller misstänkta widgetladdningar loggas. Poster skrivs med expiresAt = nu + 30 dagar och raderas via Firestore TTL när TTL-policy för widgetAbuseLog.expiresAt är aktiv. | Berättigat intresse (art. 6.1.f) — attribution, rate-limit samt missbruks- och säkerhetsspårning. Innehåller inbäddande origin, widgettyp, kommun-/skolslug, avvikelseflagga och saltad IP-hash; inga cookies. |
| 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. |
| Journalistiska databeställningar | journalist_orders | FAS-0-beslut: Firestore-posten raderas när beställningen är hanterad plus återställningsfönster, med målsättning 180 dagar från inskick. Varje post skrivs med ett purgeAfter-fält och Firestore TTL för fältet ska vara deployad och verifierad före full go-live; tills TTL är aktiv kräver FAS-0 en namngiven manuell månadsrensning. Olösta beställningar efter 180 dagar kräver dokumenterat godkännande och har 12 månaders absolut tak. Zoho Desk-biljett rensas senast 12 månader efter stängning. Zoho CRM-kontakten granskas minst årligen och beställningsspecifik status/beskrivning tas bort när den inte längre behövs. | Samtycke (art. 6.1.a) för att lagra och kontakta via formuläret; hantering av begäran/föravtalsåtgärder där tillämpligt (art. 6.1.b); berättigat intresse (art. 6.1.f) för missbruksförebyggande, operativ återställning och redaktionell relationshandoff. Ingen kampanj- eller nyhetsbrevsanvändning utan separat samtycke/proveniens. |
| 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.
Journalistiska databeställningar — manuell radering
Om du har skickat en databeställning utan konto kan du begära radering eller rättelse via info@skolkoll.se. Ange ungefärlig tidpunkt, redaktion/medium och e-postadressen som användes i formuläret. Vi söker då efter matchande journalist_orders-poster, raderar eller rättar identifierbara träffar manuellt och, om Zoho-intaget varit aktiverat, hanterar motsvarande Desk-/CRM-post där det inte finns en pågående leverans, tvist, regulatorisk begäran eller annan rättslig grund för fortsatt begränsat bevarande.
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:s ordinarie svarstid är en månad från att begäran togs emot).
Begäran om borttagning — namngivna roller i granskningen
Skolkoll visar i dag rektors namn (från Skolverkets register) på skolenhetssidorna. Företrädarnamn ur årsredovisningsdata — styrelseledamot, revisor, firmatecknare, undertecknare — behandlas i datalagret men publiceras för närvarande inte på publika ytor eller i API:t: personnamnsfälten nollas ovillkorligt i serveringslagret (namnfritt by design). Sådana namn kan däremot förekomma i redaktionella granskningsytor (t.ex. närståendegranskningar) när en konkret granskning motiverar det. Så begär du borttagning:
- Rektor: mejla info@skolkoll.se med skolans skolenhetskod. Vi tar bort uppgiften från visningen inom 14 dagar och sätter ett synkroniseringsfilter så att den inte återkommer även om Skolverket fortsätter att publicera den.
- Styrelseledamot, revisor, firmatecknare eller undertecknare: mejla info@skolkoll.se med huvudmannens organisationsnummer, din roll och var på skolkoll.se namnet förekommer (länk eller sidbeskrivning). Eftersom företrädarnamn för närvarande inte publiceras som basuppgift behöver du uppge ditt fullständiga namn endast om du pekar ut en faktisk publicering — namnet används då för att identifiera rätt post när flera personer delar samma roll och för att härleda en intern källreferens; själva spärrposten lagrar aldrig ditt namn. Begäran kan också registreras i förebyggande syfte, som spärr om publiceringsläget skulle ändras. Manuell process: vi bekräftar mottagandet inom 7 dagar och lämnar beslut inom en månad från att begäran togs emot (GDPR art. 12.3). Vid komplexa ärenden kan tiden förlängas med två månader — då meddelar vi dig inom samma enmånadsfrist från mottagandet och anger skälen. Även här spärras en borttagen uppgift mot återkomst vid kommande inläsningar.
Vill du i stället invända mot att uppgiften behandlas över huvud taget — vilket lägger bevisbördan på oss — se avsnitt 5.
5. Din rätt att invända (artikel 21 GDPR)
Denna information lämnas uttryckligen och åtskilt från övrig information, i enlighet med artikel 21.4 GDPR.
Behandlar Skolkoll dina personuppgifter med stöd av berättigat intresse (artikel 6.1 f) — det gäller bland annat basvisningen av rektorsnamn och behandlingen av företrädarroller i datalagret, se avsnitt 6 — har du rätt att när som helst invända mot behandlingen, av skäl som rör din specifika situation. Invändningsrätten gäller behandlingen som sådan, oavsett om uppgiften för närvarande visas publikt eller inte.
När du invänt får vi inte längre behandla uppgifterna, såvida vi inte kan visa tvingande berättigade skäl för behandlingen som väger tyngre än dina intressen, rättigheter och friheter. Bevisbördan ligger på oss, inte på dig.
Så invänder du: mejla info@skolkoll.se. Ange din roll och identifierare: skolenhetskod om du är rektor; huvudmannens organisationsnummer och din roll om du är styrelseledamot, revisor, firmatecknare eller undertecknare. Förekommer ditt namn på en faktisk yta, ange var det syns (länk eller sidbeskrivning) samt ditt fullständiga namn — namnet används då bara för att identifiera rätt post och härleda en intern källreferens; spärrposten lagrar aldrig namnet. Beskriv gärna också de omständigheter du åberopar. Vi bekräftar mottagandet inom 7 dagar, prövar invändningen individuellt och dokumenterat, och lämnar beslut inom en månad från att invändningen togs emot (artikel 12.3). Kan vi inte visa tvingande berättigade skäl tas uppgiften bort från visningen och spärras mot återkomst vid framtida uppdateringar från källregistren.
Är du inte nöjd med vårt beslut kan du klaga till Integritetsskyddsmyndigheten (IMY) — se avsnitt 12.
I den mån en yta omfattas av det journalistiska undantaget (1 kap. 7 § dataskyddslagen) är artikel 21 formellt inte tillämplig — vi prövar ändå varje invändning enligt ramen ovan. Rättsläget efter EU-domstolens dom i mål C-199/24 den 9 juli 2026 är föremål för extern juristgranskning (utlåtande väntas senast 21 augusti 2026); denna sida uppdateras om granskningen ändrar bedömningen.
6. Information enligt artikel 14 — namngivna roller i granskningen
Skolkoll behandlar — och visar i vissa fall — personuppgifter som inte har samlats in från de registrerade själva utan från offentliga register. Enligt artikel 14 GDPR ska de registrerade informeras om behandlingen. Den berör namngivna rollinnehavare vid cirka 16 500 skolenheter och deras huvudmän; att underrätta var och en individuellt skulle innebära en oproportionerlig ansträngning, och Skolkoll åberopar därför undantaget i artikel 14.5 b. Som kompenserande åtgärd hålls informationen i stället öppet tillgänglig här. Den kompletterar integritetspolicyn och publiceringspolicyn.
| Kategori av personuppgifter | Källa | Rättslig grund | Lagringstid / speglingslogik |
|---|---|---|---|
| Rektors namn, roll och skolenhet | Skolverkets register (öppna data) | Journalistiskt ändamål (artikel 85 GDPR, 1 kap. 7 § dataskyddslagen) för bearbetade granskningsytor; berättigat intresse (art. 6.1 f) för basvisningen på skolenhetssidorna | Uppgiften speglar källregistret och ersätts/uppdateras vid varje synkronisering. Borttagna eller invändningsfiltrerade uppgifter spärras mot återkomst via ett synkroniseringsfilter. |
| Företrädarroller hos huvudmän — styrelseledamot, revisor, firmatecknare, undertecknare (namn + roll + huvudman). Behandlas i datalagret; namnen publiceras för närvarande inte som basuppgift (se Mottagare nedan) | Bolagsverket, offentliga årsredovisningar | Journalistiskt ändamål i granskningskontext (t.ex. närståendeanalys); berättigat intresse (art. 6.1 f) i övrigt | Avregistrerade roller pseudonymiseras eller tas bort senast fem år efter avregistreringsdatum. Borttagna uppgifter spärras mot återkomst. |
Kategorier vi inte behandlar i dessa dataset: personnummer, hemadresser, privata kontaktuppgifter, privatekonomi, familjerelationer utöver den formella rollen, eller känsliga kategorier enligt artikel 9.
Personuppgiftsansvarig för denna behandling är Skolspegeln AB (org.nr 559359-7288), kontakt info@skolkoll.se. (Biträdesrollen i avsnitt 1 gäller kommunlicens-data; för granskningsbehandlingen är Skolkoll personuppgiftsansvarig.)
Mottagare: rektorsnamn är publikt synliga på skolkoll.se — på skolenhetssidor och i de öppna datafiler som driver tjänsten. Företrädarnamn ur årsredovisningsdata publiceras för närvarande inte på publika ytor eller i API:t (serveringslagret nollar personnamnsfälten ovillkorligt); de kan förekomma i redaktionella granskningsytor när en konkret granskning motiverar det. Det finns ingen personsökning (du kan inte söka på en persons namn) och inga dedikerade personuppslagssidor.
Dina rättigheter: tillgång (art. 15), rättelse (art. 16), radering (art. 17 — se avsnitt 4), begränsning (art. 18) och invändning (art. 21 — se avsnitt 5), samt rätt att klaga till IMY (avsnitt 12). I den mån behandlingen sker för journalistiska ändamål är delar av GDPR:s bestämmelser formellt undantagna (1 kap. 7 § dataskyddslagen) — Skolkoll tillämpar ändå processerna ovan som dokumenterad praxis.
Underlagen bakom detta block (intresseavvägning och pågående konsekvensbedömning) är arbetsutkast under extern juristgranskning efter EU-domstolens dom i C-199/24 (utlåtande väntas senast 21 augusti 2026). Blocket uppdateras om granskningen ändrar bedömningen.
7. 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. Slutsatsen att en fullständig DPIA inte är obligatorisk gäller behandlingen inom kommunlicens-leveransen, där kommunen är personuppgiftsansvarig och Skolkoll personuppgiftsbiträde (se avsnitt 1): den behandlingen uppfyller inte höga risk-kriterier (ingen storskalig övervakning, inga särskilda kategorier av personuppgifter sparas systematiskt, inget automatiserat beslutsfattande som har rättsliga konsekvenser för individer). För Skolkolls publika granskningsverksamhet, där Skolkoll är personuppgiftsansvarig, gäller en egen bedömning — där pågår ett separat, fullständigt DPIA-arbete (2026). Lane-D-dokumentextraktionen kan tillfälligt bearbeta råtext ur allmän handling som kan innehålla elevuppgifter innan maskering — denna exponering och dess åtgärder beskrivs i risktabellen nedan och under Internt AI-stöd.
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; borttagning på begäran inom 14 dagar (avsnitt 4) och invändningsprövning enligt avsnitt 5; synkroniseringsfiltret applicerar borttagningar 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. |
| Elevuppgifter i råtext når OpenAI före maskering vid Lane-D-dokumentextraktion | Låg × Medel | Endast offentliga handlingar (allmän handling) bearbetas; anropen görs med lagring avstängd (no-store) och OpenAI DPA/SCC gäller. Maskering tillämpas på det som sparas, ingen automatisk publicering sker, och alla kandidater passerar en människogranskad kö innan något kan publiceras. Behandlingen är begränsad till godkända dokumentlayouter och kommuner. |
8. 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").
9. 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; Zoho Desk/CRM via Zohos EU-endpoints för support och godkända databeställningar. - 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 (chatt och skolbild efter samtycke; Lane-D-extraktion och journalistmail-utkast på berättigat intresse) 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.
10. 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.
11. 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).
12. 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