Senast uppdaterad: 2026-09-26
Revisionsstatus: Dataset E:s publika gränser samt OAI-API-, ANTH-API-, Lane D-, JobEd- och inloggningsunderlagen är avstämda mot intern ROPA v3.17 och överföringsbilaga v2.9. Kollen har berättigat intresse och en tydlig instruktion att inte lämna privata eller känsliga uppgifter. ANTH-API omfattas av ett juridiskt stopp tills daterad leverantörs-/kontoevidens visar att behandlingen utanför EES är begränsad till den kod- och bilagebundna listan, för närvarande exakt USA, med DPF eller SCC och land- och mottagarspecifik TIA; ett annat land kräver kod- och bilagegranskning. En fail-closed gate finns i repositoryt, men produktionsdeploy och live-readback är inte verifierade och påstås inte här. Zoho Mail har inget positivt godkännande: nya användarinitierade inkommande förfrågningar får tas emot, bedömas manuellt och besvaras endast strikt nödvändigt efter ärendespecifik minimering och med ärendets dokumenterade grund; ingen AI används. Proaktiv eller diskretionär kontakt, kampanj-/relationsbyggande, automation, bulk och nya integrationer/funktioner/datakategorier är STOPP. Lane D är inte generellt stoppad men varje användning ska föregås av en enkel, versionsmärkt och flödesspecifik bedömning.
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
I P1–P3 är kommunen personuppgiftsansvarig och Skolkoll personuppgiftsbiträde för organisationsmedlemskap/roller, kundstyrda importer och bevakningar samt instruktionsbundna support-/incidentunderlag. Skolkoll är separat personuppgiftsansvarig för C2-identitets-/åtkomstsäkerhet, egen kund- och fakturaadministration, C4-bevakningar som en anonym besökare själv begär och andra egna ändamål i integritetspolicyn. Stripe-/faktureringsposter och publika källuppgifter ingår inte automatiskt i biträdesuppdraget.
Personuppgiftsbiträde (Skolkoll): Skolspegeln AB
Organisationsnummer: 559359-7288
Kontakt för dataskyddsfrågor: info@skolspegeln.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. Personuppgiftsbiträden, underbiträden och andra mottagare
Tabellen redovisar leverantörer per faktisk roll och behandling. En leverantör är underbiträde för kommunlicensen bara när den behandlar personuppgifter i den behandlingskedjan; Zoho Mail och Zoho Campaigns behandlar i stället Skolspegelns egna personuppgiftsansvariga aktiviteter. PuB-/DPA-villkor och överföringsmekanismer gäller där respektive roll och behandling kräver det. Leverantörer för användarvald social inloggning behandlar sitt konto- och autentiseringsled enligt egna villkor; land och överföringsmekanism bedöms leverantörsspecifikt och får inte sammanfattas som ett gemensamt USA-/SCC-scenario.
| Leverantör | Tjänst | Datakategori | Region | DPA |
|---|---|---|---|---|
| Google Cloud (Firebase) | Hosting, Firestore, Cloud Functions, Cloud Storage, Authentication, Cloud Logging | Användarkonton, organisationsdata, analyticsEvents, faktureringshistorik samt åtkomstbegränsade råa offentliga årsredovisnings-/ESEF-källor och deras källarkivmetadata. Runtime-loggar kan innehålla operativa användar-, organisations- och request-ID:n, maskerade kontaktvärden i kartlagda flöden samt runtime-/fel-/stackkontext. Just journalistbeställningsflödets nya loggar är snävare kodbegränsade till pseudonyma begäran-/dokument-ID:n och minimerad fel-/runtimeklassificering (feltyp, tillåten felkod och numerisk status); kontaktuppgifter, beställningsinnehåll, fri text och leverantörens felmeddelanden loggas inte där. | Repositorykonfiguration och godkänd målbild anger europe-west1 (Belgien) för Firestore, Cloud Functions och Cloud Storage. Arkiverad produktionsreadback 2026-09-05 styrker Firestore i europe-west1 och samtliga åtta produktionsbuckets i EUROPE-WEST1 eller EU-multiregion. Firebase Hosting använder ett globalt CDN. Firebase Authentication omfattas av Google Cloud DPA/SCC/DPF utan separat europe-west1-påstående här. Loggkonfigurationen är verifierad genom autentiserad readback 2026-09-05, efter att deploy-kontot fått roles/logging.viewer. Utfallet: applikationsloggarna låg i global och flyttades samma dygn till europe-west1 genom en ny bucket och omdirigerad _Default-sink, med oförändrad retention om 30 dagar. Revisionsloggarna (_Required, 400 dagar) ligger kvar i global i en låst bucket, som varken kan flyttas, raderas eller få sänkt retention. Inga exclusions är konfigurerade på någon sink, alltså sker ingen redaktion i routningsledet, och ingen CMEK-nyckel är satt. FAS-0-fristen 2026-08-14 passerade innan readbacken gjordes; den är nu genomförd och arkiverad. Gapet stoppade utökning och nya loggkategorier fram till dess. | 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. | Service-, transaktions-, uttryckligen begärda bevaknings- och tekniska e-postutskick (bl.a. inbjudningar, fakturor, beställda rapporter/exporter, bevakningsmail och säkerhetsvarningar). Firebase Authentication hanterar sina egna kontoverifierings- och lösenordsåterställningsmail. Resend används inte för kampanjer, nyhetsbrev eller provperiodsnurture. | E-postadress, namn, ämnesrad, e-postinnehåll (raderas efter 30 dagar hos Resend) | USA; överföring omfattas av EU:s standardavtalsklausuler (SCC) | Resend DPA |
| Zoho Corporation / Zoho Mail | Officiell, bevakad e-postlåda info@skolspegeln.se i Zoho One under en daterad interimistisk riskrestriktion utan positivt godkännande. I väntan på stängd överföringsevidens får nya användarinitierade inkommande förfrågningar — bland annat rättighets-, dataskydds-, incident-, Kommunlicens-, offert/demo-, verifierings- och journalist-/direktärenden — tas emot, bedömas manuellt och besvaras endast strikt nödvändigt efter ärendespecifik innehålls- och nödvändighetsminimering. Grunden följer ärendet: rättslig förpliktelse när den gäller; art. 6.1.b endast när den registrerade personligen är den tilltänkta avtalsparten; annars dokumenterad art. 6.1.f för att läsa, minimera och svara. Fritext antas inte vara offentlig; uppgifter enligt artikel 9/10 kräver separat dokumenterad grund eller ingen fortsatt behandling. Innehållet skickas inte till AI. Proaktiv/diskretionär kontakt, kampanj- eller relationsbyggande, automation, bulkbehandling och nya integrationer, funktioner eller datakategorier i Mail är STOPP. FAS-0-fristen 2026-08-14 passerade utan att evidensen stängdes. Stoppen kvarstår därför, och den tillåtna minimerade mottagningen fortsätter endast under pågående eskalering; Zoho Legals svar 2026-09-08 identifierar SCC Modul 3 för Zoho EU → Zoho India i löpande text. Den kontospecifika DPA:n signerades 2026-09-11, men dess Schedule 1 är artikel 28-biträdesklausulerna och anger i clause 1(f) att de inte i sig säkerställer efterlevnad av kapitel V, så överföringsmekanismen är fortfarande leverantörsuppgiven snarare än avtalad. Klausul 5.1(i) gör EES-lagring till ett avtalsvillkor, men Schedule 2 tillåter uttryckligen indisk åtkomst och upptar enbart Indien för EES-kunder, medan leverantörens egna SOC 1, SOC 2 och ISO-lokalbilagor anger Austin i USA som driftsort för support. Vår Indien-bedömning måste göras mot gällande rätt och USA-ledet saknar underlag. Mailkopian följer samma ärendelivscykel och hårda tak som grundärendet. Export, minimering och verifierad radering är fortsatt tillåtna. Detta bevisar varken kapitel V-efterlevnad eller teknisk tenant-avstängning. | Namn, e-postadress, meddelande, frivilliga bilagor och tekniska meddelandehuvuden | MX-routing pekar mot Zoho EU men används inte ensam som bevis för tenantregion. Zoho Legal uppger 2026-09-08 att data ligger i EU och att supportpersonal i Indien har fjärråtkomst under SCC Modul 3. Kontospecifikt biträdesavtal tecknat 2026-09-11; tenantregionen är fortfarande overifierad och kapitel V-mekanismen leverantörsuppgiven. Vår fokuserade Indien-bedömning mot gällande rätt och USA-underlaget återstår. | Zohos publicerade DPA/SCC-villkor |
| Zoho Corporation / Zoho Campaigns | Utsedd separat plattform för kampanjer och nyhetsbrev, inte en del av sajtens Resend-flöde. Den 29 juli 2026 observerades att funktionerna för fullständig öppnings- och länkklicksspårning var påslagna. Nästa utskick och varje utskicksförmögen automation är STOPP tills ansvarig med kontospecifik evidens har uteslutit oavsiktliga automationer, verifierat DPA/SCC, genomfört daterade avregistrerings- och RTBF-test, verifierat retention/suppression, stängt spårningen eller dokumenterat separat ändamål/LEK-ePrivacy/granulärt samtycke/återkallelse samt godkänt utskicket manuellt. Grinden är inte tenant-tekniskt verifierad. | E-post, namn, organisation/språk, samtyckesproveniens, lista/segment, leveransstatus, suppression, öppningar och länkklick. Spårningen kräver separat ändamål, LEK 9 kap. 28 §-/ePrivacy-bedömning, granulärt informerat samtycke och lika enkel återkallelse om inget strikt lagundantag dokumenterats, eller daterat bevis på att den inte används för utskicket. | SPF-routing pekar mot Zohos EU-avsändare men används inte ensam som bevis för tenantregion. Zoho publicerar information om möjlig supportåtkomst och underbiträden utanför EU/EES. Den konto-/avtalsspecifika inkorporeringen, tenantregionen och överföringsbedömningen har inte verifierats i denna revision och följs upp som leverantörsevidens. | Zohos publicerade DPA/SCC-villkor |
| Functional Software, Inc. (Sentry) | Felövervakning i webbläsarfrontend; inte Cloud Functions | På vanliga publika sidor felmeddelanden och stacktrace. På den inloggade betalytan (/konto, /en/account) laddas Sentry inte om inte bygget uttryckligen tillåter det, sedan 2026-09-05: SKOLKOLL_SENTRY_ACCOUNT_ENABLED är en fail-closed byggrind, och utan ett uttryckligt sant värde renderas bootstrappen inte där. Att ta bort variabeln är en kill switch. Beskrivningen nedan gäller därför vad som skulle samlas in om grinden öppnades: eventet reduceras till event-id, release, grov kontoyta, felklass och stackposition; identitet, request/response, URL-query, breadcrumbs, DOM/input och godtyckligt context tas bort. Webbläsare/OS kan behandlas av SDK:n och käll-IP når Sentrys nätverkskant. Den separata projektinställningen för IP-skrubbning har inte verifierats genom live-readback, så full IP påstås varken alltid tas bort eller aldrig lagras. | Repositoryts CSP tillåter den tyska ingest-originen ingest.de.sentry.io, men produktions-DSN, eventregion, faktisk lagringsregion och IP-skrubbningsinställningen har inte verifierats genom live-readback; ingen positiv live-region eller IP-radering påstås. SCC krävs 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 publicerar standardiserade DPA/SCC-villkor, men kontoinkorporering, live tenantregion/plan och den fokuserade överföringsnoten är ännu inte verifierade och ingår i den kvartalsvisa evidenskontrollen | Zohos publicerade standardvillkor för GDPR/DPA/SCC |
| Google Ireland Ltd / Google LLC — Google Analytics 4 | Kodmässigt STOPP. GA4_LEGAL_RELEASE_APPROVED = false hindrar att mät-ID exponeras eller laddaren startar; en miljövariabel kan inte ensam öppna vägen. Produktionsdeploy och live-readback återstår. | Ingen aktuell överföring från repositoryvägen. Ett framtida flöde kan omfatta nätverksmetadata, sidvisningar, enhets- och ungefärlig platsinformation. | Ingen aktuell mottagarregion görs gällande. Framtida release kräver sluten mottagar-/landlista och tillämpligt adekvansbeslut eller SCC/TIA. | Avtalsroll, konto-/produktvillkor, inställningsreadback, 14-månadersmål och överföringsmekanism är release-evidens; inget positivt godkännande. |
| CARTO | Kodmässigt STOPP. Den direkta externa tile-begäran är borttagen från repositoryts kartkod; produktionsdeploy och live-readback återstår. | Ingen aktuell överföring från repositoryvägen. En framtida tile-tjänst skulle få IP-/förfrågningsmetadata och karttilekoordinater. | Ingen aktuell mottagarregion görs gällande. Återöppning kräver en sluten mottagar-/landlista och överföringsbedömning. | Roll, villkor, nödvändighet och eventuell artikel 28-/kapitel V-mekanism måste dokumenteras före granskad kodändring. |
| Zoho Corporation / Zoho Desk | Den separata Desk-supportytan tar inte emot nya ärenden. Nya användarinitierade supportförfrågningar tas i stället emot och bedöms manuellt via info@skolspegeln.se under Zoho Mail-restriktionen. Den nuvarande journalistkopplingen är ett kodmässigt STOPP oavsett generell tenant-, avtals- eller retentionsevidens: kontaktmodellen saknar beställningsbindning och testad samtidig radering/minimering. Journalistbeställningar lämnas inte till Desk och fullständigt reservmail finns inte. | För ett framtida separat godkänt supportflöde: minsta nödvändiga namn, e-postadress, organisationstillhörighet, ärendeinnehåll, ärendehistorik och frivilliga tekniska bilagor. En framtida journalistlösning måste använda ett beställningsbundet objekt utan sammanblandning med andra ändamål. Ingen automatisk AI-analys, riskklassning eller privat analyskommentar skapas. | Zoho publicerar en EU-hostad Desk-endpoint och standardiserade DPA/SCC-villkor, men kontoinkorporering, live tenantregion/plan och den fokuserade överföringsnoten är ännu inte verifierade; ytan är stoppad och är en kvartalsvis evidenspunkt | Zohos publicerade standardvillkor för GDPR/DPA/SCC |
| Zoho Corporation / Zoho CRM | Den nuvarande journalistkopplingen är ett kodmässigt STOPP oavsett generell evidens eller flaggor: den globala e-postdeduplicerade kontaktmodellen är inte beställningsbunden. Ingen journalistbeställning lämnas till CRM. En framtida ersättningslösning kräver beställningsbundna objekt och testad samtidig radering/minimering innan kodstoppet tas bort i samma granskade ändring. | Ingen aktuell CRM-post. För en framtida godkänd ersättningsdesign: minsta beställningsbundna kontaktmetadata utan beställningsfritext, Description, sammanblandning med andra ändamål eller senare relations-/kampanjkontakt. | Publik EU API-endpoint via www.zohoapis.eu. Zoho publicerar standardiserade DPA/SCC-villkor, men kontoinkorporering, live tenantregion/plan och den fokuserade överföringsnoten är ännu inte verifierade; ytan är stoppad och är en kvartalsvis evidenspunkt | Zohos publicerade standardvillkor för GDPR/DPA/SCC |
| Anthropic / OpenAI | Den användarinitierade AI-chatten "Kollen", AI-baserad skolbildsstilisering efter antingen formulärflödet med ett aktuellt servervaliderat samtycke och en hashbunden kontroll eller en separat rättighetskontrollerad importgrind utan formulärsamtycke, samt intern dokumentextraktion (Lane D). Journalistmail ingår inte i AI-flödet. Se "Internt AI-stöd" nedan. | Kollen behandlar användarens chatmeddelande och skolkontext; användaren instrueras att inte lämna privata eller känsliga uppgifter. Skolbildsstilisering skickar bildfilen till OpenAI, men inte kontaktuppgifter, fotografnamn, rättighetsinnehavare, källänkar, fotodatum eller fri text från formuläret. Lane D behandlar underlag från offentliga handlingar efter en enkel flödesspecifik bedömning. Kollen- och Lane D-anrop använder leverantörernas dataskyddsinställningar enligt det aktuella flödet; detta är inte ett påstående om ZDR. Journalistmail skickas inte automatiskt till en AI-leverantör. | OpenAI: USA och de individuellt namngivna länder och mekanismer som godkänts i dess scenario. Anthropic: API-data lagras i USA; inget annat land utanför EES är godkänt medan leverantörens regionangivelse för Europa, Asien och Australien saknar fullständig landlista. Kollen-anrop omfattas därför av ett juridiskt STOPP tills daterad leverantörs-/kontoevidens visar att behandlingen utanför EES är begränsad till exakt USA, med DPF eller SCC och land- och mottagarspecifik TIA enligt överföringsbilaga v2.9. Repositoryt innehåller en fail-closed gate; produktionsdeploy och live-readback är väntande. Ett annat land kräver kod- och bilagegranskning före anrop. | Anthropic DPA · OpenAI DPA |
| Identitetsleverantörer (Google, Microsoft, GitHub, Facebook/Meta; Apple ännu inte lanserad) | Användarvald social inloggning (OAuth/OIDC) för Skolspegelns C2-kontosäkerhet. Inga extra leverantörsbehörigheter läggs till. Apple är dolt som nytt inloggningsval tills produktionskonfigurationen verifierats. | Grundläggande identitet för inloggning, normalt namn och e-postadress, från vald leverantör | Leverantörsspecifik: Google globalt; Microsoft beroende på tenant; GitHub konservativt USA; Meta globalt. Faktisk mottagare avgör om adekvans, DPF eller SCC används. | Respektive leverantörs kontovillkor och integritetsinformation; leverantören är självständigt ansvarig för sitt konto-/autentiseringsled. |
| Kundens organisations-IdP (SAML/OIDC) | Kundstyrd inloggning för kommunlicens (P1), endast efter en organisations- och leverantörsspecifik bedömning och tekniskt p1Approved-godkännande | Arbets-e-post, stabil leverantörsidentitet och de organisations-/rollanspråk som kunden har instruerat och godkänt | Fastställs per kund och IdP innan aktivering; saknat godkännande stoppar upptäckt, verifiering, auto-anslutning, framtvingande och reautentisering. | Kundens instruktion, PuB-avtal och leverantörsspecifik roll-/artikel 28-/överföringsevidens krävs före aktivering. |
AI-behandling av skolbilder
Före ett nytt modellanrop gäller en av två alternativa grindar. En bild från skolbildsformuläret kräver aktuell servervaliderad AI-samtyckes-/policyversion och en positiv redaktionell kontroll, bunden till aktuell bildhash, licens-/rättighetsintyganden och exakt eventuell författarlänk, som bekräftar rättighetsgrunden och att bilden saknar identifierbara personer. En separat rättighetskontrollerad import kräver inte och påstår inte formulärsamtycke; den kräver i stället en separat positiv importkontroll, bunden till aktuell bildhash och käll-/licens-/rättighetsbevis, tillsammans med LIA §7.1 och tillämplig artikel 14-proveniens. Den nuvarande schoolImageSubmissions.aiEligibilityReview implementerar endast formulärgrinden, så importspåret måste ha ett separat registrerat granskningsbevis före modellbehandling. Saknad eller avvikande kontroll stoppar nya anrop och återförsök; redan slutförd behandling som uppfyllde sin tillämpliga grind behöver inte regenereras. För en formulärbild publiceras fotografnamn och exakt kontrollbunden HTTPS-länk bara när CC BY 4.0 eller CC BY-SA 4.0 kräver det. När insändaren själv är fotograf registrerar den aktuella v3-kontrollen direktinformation genom den versionsbundna insamlingsnotisen. En namngiven tredjepartsfotograf ska annars få direkt information inom artikel 14.3:s frister. Artikel 14.5 b får ersätta direkt information först när ett daterat och signerat juridiskt underlag uttryckligen har registrerats för den exakta källan och publiceringen; det tomma serverstyrda registret är fail-closed. Spårnings-ID:t LIA-SCHOOL-IMAGE-ATTRIBUTION-14.5B-2026-07-30 aktiverar inte undantaget: en verifierad tidigare attributionskälla måste fortfarande vara dokumenterad för samma källa och publicering. Äldre school-image-ai-eligibility-v2-author-url-bound-bevis får inte publicera namn eller länk och måste omgranskas; själva chalkbilden behöver inte regenereras. CC0 samlar och publicerar inget fotograf-/rättighetshavarnamn och ingen person-/källänk. Ett frivilligt fotodatum används bara vid granskning och publiceras inte. Skolkoll kör inget separat AI-modereringssteg. Endast bildfilen och en statisk stilinstruktion skickas till OpenAI — inte kontaktuppgifter, fotografnamn, rättighetsinnehavare, källänk, fotodatum eller fri text. Enligt OpenAI Data Controls, kontrollerad 2026-07-29, har bildflödets /v1/images/edits ingen application-state-lagring. Standardiserade loggar för missbruksövervakning kan ändå behållas i upp till 30 dagar; bildinnehåll som flaggas av leverantörens säkerhetssystem kan hållas för manuell säkerhetsgranskning, och längre bevarande kan förekomma när det krävs för säkerhet eller rättsliga skyldigheter. Det är endpointspecifika undantag och inget påstående om ZDR.
Internt AI-stöd
Kollen. Chatten aktiveras av användaren och behandlar frågan med stöd av berättigat intresse (art. 6.1.f) enligt en dokumenterad intresseavvägning. Gränssnittet instruerar användaren att inte skriva privata eller känsliga uppgifter. Den instruktionen är den beslutade förebyggande skyddsåtgärden; någon generell teknisk spärr mot fri text påstås inte. Instruktionen är däremot inget undantag från artikel 14 om en användare ändå lämnar uppgifter om någon annan. Den öppna informationen här och en dokumenterad proportionalitetsbedömning används som kompenserande åtgärder; om Skolkoll får konkret kännedom om personen och har kontaktuppgifter lämnas individuell information inom den tid som följer av artikel 14.3, om inget tillämpligt undantag dokumenteras. Kollen är inte godkänd för uppgifter enligt artikel 9 eller 10. Om Skolkoll i ett konkret fall får kännedom om att sådant innehåll ändå har lämnats, stoppas fortsatt användning av innehållet i den sessionen; det återanvänds eller innehållsloggas inte, och incident-/riskbedömning görs utan att kopiera innehållet. Den rättsliga grunden ersätter inte tredjelandsgrinden: inget anrop får ske medan Anthropic kan dirigera behandling utanför EES till ett icke namngivet land.
Dokumentextraktion (Lane D, OpenAI). Officiellt publicerade offentliga handlingar får användas efter en enkel, dokumenterad och versionsmärkt bedömning för den aktuella kommun-/portal-/layoutströmmen. Repositorykontrollerna förkontrollerar hela dokumentet före varje modellanrop: privata källmarkörer, personnummer/elevidentifierande sammanhang och indikatorer på uppgifter enligt artikel 9 eller 10 stoppar dokumentet, medan e-post och telefon tas bort ur den separata leverantörskopian. Klassificeringen kan ge falska negativa och detta är en kvarvarande risk. Kontrollerna är implementerade och testade i repositoryt, men produktionsdeploy och live-readback är väntande; ingen produktionsanvändning godkänns på grundval av denna text innan de har verifierats. Ingen extraherad uppgift publiceras automatiskt: kandidater går till en människogranskad kö. Rättslig grund är berättigat intresse (art. 6.1.f); varken ZDR eller dokument-för-dokument-prövning är ett generellt krav för denna avgränsade offentliga kategori. Lane D använder /v1/chat/completions med store: false, vilket innebär att inget response application state skapas för flödet. Det utesluter inte leverantörens övriga lagringsvägar: prompt caching kan behålla krypterade KV-tensorer i GPU-lokal lagring i upp till 24 timmar, standardiserade missbruksövervakningsloggar kan behållas i upp till 30 dagar och längre bevarande kan förekomma när det krävs för säkerhet eller rättsliga skyldigheter. Flödet beskrivs därför inte som lagringsfritt eller ZDR.
Journalistmail och andra användarinitierade direktförfrågningar. Ett nytt inkommande ärende får tas emot, bedömas manuellt och besvaras endast strikt nödvändigt efter ärendespecifik innehålls- och nödvändighetsminimering under Zoho Mails daterade interimistiska riskrestriktion. Grunden följer ärendet enligt leverantörsraden ovan; fritext antas inte offentlig och artikel 9/10-innehåll kräver separat grund eller ingen fortsatt behandling. Meddelandeinnehållet skickas inte till Anthropic, OpenAI eller någon annan AI-tjänst. Proaktiv/diskretionär kontakt, kampanj-/relationsbyggande, automation, bulk och nya integrationer/funktioner/datakategorier är STOPP. FAS-0-fristen 2026-08-14 passerade utan att evidensen stängdes; endast den minimerade mottagningen fortsätter, under pågående eskalering till en laglig ersättningskanal.
För P1–P3-kommunlicensdata anlitar vi inga reklamnätverk, marknadsföringsplattformar eller sociala media-pixlar. Zoho PageSense kan köras först efter explicit cookiesamtycke från besökare på publika, indexerbara sidor. Google Analytics 4 är dessutom kodmässigt stoppat genom GA4_LEGAL_RELEASE_APPROVED = false oavsett samtycke; ett framtida öppnande kräver en granskad kodändring och full release-evidens. För inloggade kommunanvändare körs ingen PageSense-spårning. 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. | P1: kundens dokumenterade instruktion för medlemskap/roll. C2: berättigat intresse (art. 6.1.f) för nödvändig identitets-, åtkomst- och säkerhetsadministration; art. 6.1.b endast när den registrerade personligen är avtalspart. |
| 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 tills vidare. | 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. Live-readback 2026-07-30 visade widgetAbuseLog.expiresAt som ACTIVE; detta bevisar policystatus, inte att ett visst utgånget stickprov har raderats. Firestore-raderingen sker asynkront efter fristen. | 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. |
| Äldre mail-kontakter och kampanjposter | mailContacts, mailContactEmailClaims, mailLists, mailCampaigns, mailSends, mailWebhookEvents | Det egna kampanjsystemet är pensionerat och gör inga nya utskick. Tidsfristerna är absoluta tak och utgör inte i sig laglig grund. Efter den gamla sjudagars länkgracen raderas poster utan ett aktuellt, kollektionsbundet C5-beslut; ett giltigt beslut medför omedelbar minimering. Allt annat raderas tidigare. Den pensionerade unikhetsreserveringen mailContactEmailClaims raderas alltid och används inte som en andra suppressionkopia. Tak: bekräftelselänk 48 timmar, avregistreringslänk 7 dagar, osänt inaktivt utkast 90 dagar, webhookhändelse 30 dagar och minimerat bevis/suppression 24 kalendermånader. Repositoryt innehåller ett dagligt cleanupjobb och en dry-run-first engångsmigrering, men produktionsdeploy, liveinventering och genomförd gallring är ännu inte verifierade. | Samtycke bar endast det historiska nyhetsbrevsutskicket och behandlingen före återkallelse. Efter återkallelse eller ändamålsslut kräver minsta bevis/suppression ett konkret C5-ändamål och art. 6.1.c där en specifik skyldighet gäller, annars en dokumenterad intresseavvägning enligt art. 6.1.f. Tekniska mail och bevakningar hanteras i separata system. |
| Pensionerade provperiodsnurture-markörer | trialNurtureSent samt tidigare onboardingfält på organisationsposten | Engångsrensning efter driftsättning tar bort kollektionen och fälten trialOnboardingGuideSendingAt, trialOnboardingGuideSentAt och trialOnboardingGuideProgress. Migreringen kräver uttrycklig projektbekräftelse före körning. | Markörerna bevisar inte samtycke eller annan laglig grund för de historiska provperiodsutskicken, och ingen sådan grund görs gällande retroaktivt. Nuvarande åtkomst begränsas till nödvändig pensionering, radering och ansvarsskyldighet enligt art. 6.1.c där en skyldighet gäller, annars art. 6.1.f. |
| Kampanj- och nyhetsbrevskontakter | Zoho Campaigns (extern tjänst, inte Firestore) | Skolspegelns styrande mål är aktiva kontaktuppgifter tills återkallelse, avregistrering eller ändamålsslut samt högst 24 månader för minsta suppression-/samtyckesbevis och identifierbara mottagarrapporter. Ett specifikt befintligt eller hotande anspråk kräver en separat C5-kontroll. Kontoets faktiska raderings-/RTBF-konfiguration och verkställighet av 24-månadersmålet har inte attesterats i denna revision och följs upp som leverantörsevidens; leverantörens möjliga femårsmaximum har inte antagits som Skolspegelns lagringstid. | Utskick och separat godkänd spårning: samtycke (art. 6.1.a) samt separat MFL- och LEK 9 kap. 28 §-/ePrivacy-prövning. Efter återkallelse används inte samtycket som grund; minsta bevis/suppression stöds av art. 6.1.c där GDPR/MFL kräver det, annars dokumenterad art. 6.1.f-intresseavvägning för att förhindra ny kontakt eller försvara ett anspråk. |
| Granskningslogg (audit log) | auditLog | 2 år. Varje ny post skrivs med expiresAt = nu + 2 år. Live-readback 2026-07-30 visade auditLog.expiresAt som ACTIVE; detta bevisar policystatus, inte att ett visst utgånget stickprov har raderats. TTL-radering är asynkron efter att tiden passerat. | Berättigat intresse (art. 6.1.f) — säkerhet, spårbarhet, behörighetskontroll och tvist-/incidentutredning. |
| Pseudonym kontoraderingsaudit | accountDeletionAudit | Högst 12 månader via expiresAt, oavsett om status visar slutförd radering eller ett retrybart/blockerat steg. Dokument-id och kontoreferens är separata domänavgränsade SHA-256-hashar; posten innehåller subjectHash, e-posthash, status, säkra felsteg och städningsräknare men varken rå uid eller rå e-postadress. Den är inte ett fortsatt konto. Live-readback 2026-07-30 visade policyn som ACTIVE, vilket inte bevisar asynkron radering av ett visst utgånget stickprov. | Berättigat intresse (art. 6.1.f) för minsta bevis om genomförande eller misslyckat steg; art. 5.2 är ansvarsskyldighet och inte en egen laglig grund. |
| API-användningskvot | apiQuota/{orgId}/months/{YYYY-MM} | 13 månader (för faktureringskontroll och dispyt). | Kundinstruktion för kundstyrd kvot; Skolkolls separata kvot-, faktura- och tvistkontroll: berättigat intresse (art. 6.1.f). Art. 6.1.c endast när ett konkret bokföringskrav omfattar uppgiften. |
| Bevakningar | watchers, watcherEvents | Aktiva bevakningar lagras tills användaren avslutar dem, raderar kontot eller kundinstruktionen upphör. Väntande bekräftelser har 48 timmars tokenfönster. Vid avregistrering raderas e-post, bekräftelse-/avregistreringstoken och övriga direkta bevakningsfält omedelbart; ett minimerat stängningstombstone med hash, status och stängnings-/utgångsklockor får endast ligga kvar för dokumenterad suppression/ansvarighet och högst 24 kalendermånader, med tidigare radering vid ändamålsslut. Det dagliga cleanup-jobbet backfyller äldre stängda poster, minimerar dem och raderar tombstones när klockan löpt ut; produktionsdeploy, första körning och live-readback är ännu inte verifierade. watcherEvents rensas normalt inom 35 dagar. | C4: samtycke (art. 6.1.a) för anonym dubbel opt-in. P2: kundens dokumenterade instruktion för organisationsstyrd Kommunlicens-bevakning. Art. 6.1.b endast när den registrerade personligen är avtalspart. |
| Kommersiella leadformulär | leadSubmissions | 90 dagar via purgeAfter. Live-readback 2026-07-30 visade TTL-policyn som ACTIVE, vilket inte bevisar ett utgånget stickprov. Posten innehåller namn, e-post, organisation, telefon, meddelande, spår/yta, språk, versionsmärkt artikel 13-notis och UTM-fält. Formuläret instruerar att privata, känsliga eller andra personers uppgifter inte ska lämnas. Fritext ligger bara i den åtkomstbegränsade Firestore-posten för manuell hantering och skickas aldrig till CRM Description; inget pensionerat marknadsföringssamtyckesfält samlas in. Z-CRM är STOPP och skapar ingen ny leverantörspost. | Art. 6.1.b endast när den registrerade personligen är blivande avtalspart; annars dokumenterat berättigat intresse (art. 6.1.f) för nödvändig teknisk mottagning och åtkomstbegränsad lagring, ärendespecifik manuell minimering/svar, missbruksförebyggande och operativ återställning. AI-/innehållsanalys och proaktiv kontakt ingår inte. Oväntade artikel 9-/10- eller tredjepartsuppgifter kräver separat grund/villkor eller minimeras/raderas. |
| Rättelseformulär för publicerad skoldata | correctionSubmissions | Personuppgiftsansvarigs mål: e-post, eventuellt namn (bara vid manuell eller API-registrering), user-agent och fritext raderas eller anonymiseras 90 dagar efter avslutat ärende, senast 12 månader efter mottagandet; kvar blir avidentifierad ärendefakta. Rättighetsärenden (art. 15–21), även manuellt införda e-postärenden av den typen, följer i stället C5:s bevisklass. Ingen automatisk gallring är driftsatt (kontrollucka); läge 2026-09-03: ingen post har gallrats. Manuellt införda e-postärenden ligger i samma kollektion och följer samma mål. Posten innehåller skola/sida, feltyp, fritext, eventuell länk, källänk och skolenhetskod, valfri e-post, språk, user-agent och mottagningstid; ingen IP-adress i posten. | Dokumenterat berättigat intresse (art. 6.1.f) för nödvändig teknisk mottagning, åtkomstbegränsad lagring, ärendespecifik minimering och det svar formuläret erbjuder. En rapport om den registrerades egna uppgifter hanteras som rättighetsbegäran (art. 15–21) med art. 12.3-fristen från mottagandet. |
| Kommunlicens-demo | demoSessions (intaget borttaget i koden 2026-09-07; upphör i produktion vid driftsättning, lagring pågår) | Raderas i sin helhet. Den schemalagda gallringen togs bort med endpointen. TTL-overriden på purgeAfter behålls men täcker inte allt: fältet infördes 2026-08-01 medan demon gick live 2026-05-05, så poster däremellan saknar purgeAfter och rörs aldrig av TTL. Den fältvisa 30-dagarsredigeringen av rå IP och user-agent gjordes av jobbet och kan inte utföras av TTL. Engångsraderingen — måldatum 2026-09-21, ansvarig Sales privacy owner, med readback som visar noll dokument — omfattar verifierat endast Firestore-dokumenten i demoSessions. Produktionens PITR-fönster, backup-exporter och e-postleverantörens (R-EMAIL) mottagar-, meddelande- och tokenmetadata ligger utanför den verifieringen och följer sina egna scheman. TTL-overriden tas bort först när readbacken finns. | Historisk grund, oförändrad för de poster som finns kvar: för en användarinitierad lead-/demoförfrågan används art. 6.1.b endast om den registrerade personligen är den blivande avtalsparten; annars dokumenterad art. 6.1.f-bedömning för nödvändig manuell mottagning, ärendespecifik minimering, svar och missbruksskydd vid en självbegärd B2B-demo. Ändamålet upphörde med demon, så ingen grund kvarstår för fortsatt lagring och radering är förfallen enligt art. 5.1.e/17.1.a. |
| Begärd bevakning av datahändelser | dataEventSubscriptions | Obekräftade dubbel-opt-in-poster rensas efter cirka 30 dagar via confirmExpiresAt; TTL-policyn verifierades ACTIVE den 2026-07-26. Bekräftade bevakningar lagras tills avregistrering. Vid avregistrering ska hela dokumentet raderas omedelbart; ingen inaktiv post, tombstone eller suppression-hash får sparas. En separat backfill ska rensa äldre restposter från tidigare beteende. Den äldre adressen /api/newsletter/** är en kompatibilitetsväg: den registrerar ingen kampanj-/nyhetsbrevsprenumeration och utskicken innehåller bara matchande offentliga datahändelser och servicelänkar. | Samtycke (art. 6.1.a) för den uttryckligen begärda bevakningen. |
| 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. Live-readback 2026-07-30 visade att den exakta TTL-policyn är ACTIVE; det bevisar konfigurationsstatus, inte att ett visst utgånget stickprov redan har passerat Firestores asynkrona raderingscykel. Olösta beställningar efter 180 dagar kräver dokumenterat godkännande och har 12 månaders absolut tak. De nuvarande Desk-/CRM-modellerna är kodmässigt stoppade och skapar ingen leverantörspost. En framtida godkänd ersättningslösning ska radera hela den beställningsbundna leverantörsposten när beställningsändamålet upphör eller samtycket återkallas, och alltid senast vid beställningens hårda maxgräns. Längre lagring kräver ett separat framtida ändamål, rättslig grund och information. Beställningens fritext och ett Description-fält får inte skickas till CRM. | Samtycke (art. 6.1.a) för att lagra och hantera formulärbeställningen samt lämna kontaktsvar. Art. 6.1.b används endast om den registrerade personligen är den blivande avtalsparten och har begärt föravtalsåtgärder. Berättigat intresse (art. 6.1.f) används endast för nödvändigt missbruksförebyggande och operativ återställning, inte för beställningshantering, kontaktsvar, redaktionell uppföljning eller en fortlöpande relation. Ingen kampanj- eller nyhetsbrevsanvändning utan separat samtycke/proveniens. |
| Skolbildsbidrag och rättighetsuppgifter | schoolImageSubmissions | Väntande bidrag förfaller för radering 180 dagar efter uppladdning även efter återgång till granskning; avvisade bidrag förfaller 90 dagar efter beslut. För godkända bilder bevaras minsta bild-, licens-, attributions-, käll- och granskningsproveniens så länge bilden används eller rättighetsanspråk rimligen behöver kunna hanteras. Kontaktuppgifter, fotodatum, granskningsfritext och andra intagsfält förfaller för minimering 180 dagar efter godkännandet; äldre CC0-namn och länkar omfattas av samma pass. Det dagliga cleanup-jobbet verkställer radering eller minimering vid nästa lyckade körning som når posten; kö eller driftfel kan fördröja verkställigheten. Fotodatumet publiceras aldrig för en formulärbild. | För formulärinskick: samtycke (art. 6.1.a) endast för uppladdarens egna kontaktuppgifter och valda AI-behandling, tillsammans med licensavtalet. När CC BY 4.0 eller CC BY-SA 4.0 kräver attribution behandlas och publiceras fotografens namn och en eventuell exakt bildhash-/licens-/URL-kontrollbunden HTTPS-länk med stöd av berättigat intresse (art. 6.1.f) och tillämplig artikel 14-väg. En namngiven tredjepartsfotograf ska få direkt information inom artikel 14.3:s frister; artikel 14.5 b får ersätta direkt information först när daterat och signerat juridiskt underlag har registrerats för den exakta källan/publiceringen. Det tomma serverstyrda registret är fail-closed. CC0-intag och CC0-projektion innehåller ingen personattribution. |
| Kö för publikt återkallande av skolbild | schoolImageSubmissions.imagePurge med queryfältet imagePurge.dueAt | Kö- och retryfält följer inskicks-/raderingsärendets schema och minimeras efter verifierat utfall. processing.publicUnrecoverableAt betyder verifierad publik oåtkomlighet efter radering av aktiv generation eller ett redan publikt frånvarande objekt; det bevisar inte fysisk radering av alla providerbytes. non_current_generation får inte finalisera utan går till retry/återinventering. Soft delete/providerretention kan kvarstå efter publik oåtkomlighet. | Art. 6.1.c när en konkret raderings-/rättighetsskyldighet gäller, annars dokumenterat berättigat intresse (art. 6.1.f) för säker verkställighet och ansvarighet. |
| Pseudonymiserad raderingsaudit för förfallna väntande/avvisade skolbilder och omedelbart raderade personbilder | imageCleanupAudit | 24 kalendermånader från det raderingsankare som postens deletionScope anger: källpostens radering vid vanlig retention-cleanup, eller verifierad bildfilradering vid omedelbar personbildspurge där den bildlösa källposten finns kvar till sin ordinarie frist. Varje ny post skrivs med expiresAt = deletedAt + 2 kalenderår. Om Storage-radering återstår är status pending_storage; först efter bekräftad radering av de berörda filerna sätts completed och storageCompletedAt, utan att den tidigare sluttiden flyttas. Personbildspurgens auditpost är best-effort så att ett auditfel aldrig blockerar bildraderingen; det varaktiga purge-tillståndet finns i källposten. En avgränsad migrering som endast kortar äldre sluttider finns förberedd, men dry run, verkställighet, äldre statusavstämning och efterkontroll i produktion är ännu inte dokumenterade. Live-readback 2026-07-30 visade imageCleanupAudit.expiresAt som ACTIVE; detta bevisar policystatus, inte att äldre sjuåriga sluttider har kortats eller att ett visst utgånget stickprov har raderats. Posten är en minimerad men pseudonym personuppgift: den innehåller submissionId, cutoff-datum, raderingsorsak, scope, status, raderings-/slutförandetid och eventuell HMAC-SHA-256-hash av kontaktmejl — inte rå kontaktdata, bildfil, skolnamn eller fritext. Ett konkret rättsligt anspråk hanteras i en separat åtkomstbegränsad bevispost med egen frist och förlänger inte denna auditpost. | Berättigat intresse (art. 6.1.f) och ansvarsskyldighet enligt GDPR art. 5.2 — under en proportionerlig normalperiod kunna svara på status för den scope-definierade raderingen 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. | Berättigat intresse (art. 6.1.f) enligt dokumenterad intresseavvägning — användarinitierad frågetjänst med instruktion att inte lämna privata eller känsliga uppgifter. |
| AI-granskningslogg | ai-audit-log | Varje post skrivs med expiresAt = nu + 90 dagar. Live-readback 2026-07-30 visade ai-audit-log.expiresAt som ACTIVE; detta bevisar policystatus, inte att ett visst utgånget stickprov har raderats. TTL-radering är asynkron efter att tiden passerat och kan inte garanteras exakt dag 90. | Berättigat intresse (art. 6.1.f) — pseudonymiserad 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 gör servern högst ett asynkront skrivförsök till Firestore-kollektionen ai-audit-log per berättigad behandlad Kollen-förfrågan. Svaret väntar inte på skrivningen, fel loggas och att en post lagras kan därför inte garanteras. En lagrad post innehåller anropstyp, en nycklad och domänseparerad HMAC-SHA-256-pseudonym för IP-adressen som förkortats till 16 tecken, skolkontext som exakt åttasiffrig skolenhetskod eller null, 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. Live-readback 2026-07-30 visade ai-audit-log.expiresAt som ACTIVE; detta bevisar policystatus, inte att ett visst utgånget stickprov har raderats. Firestores TTL-mekanism raderar posten asynkront efter expiresAt; TTL är inte en exakt raderingstidpunkt.
Vid begäran om tidigare radering kontaktar du info@skolspegeln.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@skolspegeln.se. Ange skola, ungefärlig uppladdningstid och den e-postadress som användes i formuläret. Avvisade bidrag förfaller för radering 90 dagar efter beslutet och verkställs av nästa lyckade dagliga cleanup-körning som når posten. Cleanup-flödet lämnar en minimal, pseudonymiserad auditpost i imageCleanupAudit. Köfältet imagePurge.dueAt gör väntande ärenden querybara. Endast verifierad radering av den aktiva generationen eller ett redan publikt frånvarande objekt får sätta publicUnrecoverableAt; en icke aktuell generation går till retry/återinventering. Tidsstämpeln betyder publik oåtkomlighet, inte att soft-delete-fönster, providerretention eller alla fysiska bytes bevisligen är borta. 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@skolspegeln.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 och raderar eller rättar identifierbara träffar manuellt 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. De nuvarande journalistkopplingarna till Desk/CRM är kodmässigt stoppade och skapar ingen leverantörspost. Om en äldre Desk-/CRM-post från tidigare drift faktiskt finns i karantän omfattas den av samma rättelse- eller raderingsbedömning, med förbehåll för en eventuell rättslig grund för fortsatt begränsat bevarande. En framtida godkänd ersättningslösning måste kunna verkställa motsvarande rättelse eller radering i samma beställningsbundna livscykel.
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 kontobundna bevakningar och din profilinformation raderas från de aktiva tjänstekollektionerna. En separat pseudonym raderingsaudit utan rå e-post kan ligga kvar högst 12 månader för genomförandestatus eller ett retrybart/blockerat steg.
Vad raderas inte automatiskt med kontot: Faktureringshistorik bevaras 7 år enligt bokföringslagen. Granskningsloggposter (auditLog) har 2 års retention. accountDeletionAudit använder hashat dokument-id och subjectHash och behåller e-posthash, status, säkra felsteg och städningsräknare i högst 12 månader; den innehåller varken rå uid eller rå e-post och är inte ett fortsatt konto. Live-readback 2026-07-30 visade båda TTL-policyerna som ACTIVE; detta bevisar policystatus, inte ett utgånget stickprov, och raderingen sker asynkront efter fristen. 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 info@skolspegeln.se. Vi bekräftar mottagandet inom 1 arbetsdag. Vårt interna mål är att fatta ett individuellt beslut och, om begäran beviljas, genomföra raderingen inom 14 dagar. Information om vilka åtgärder som har vidtagits lämnas utan onödigt dröjsmål och senast inom en månad från att begäran togs emot enligt artikel 12.3. Vid behov kan fristen förlängas med högst två ytterligare månader med hänsyn till begärandenas komplexitet och antal; då får du besked om förlängningen och skälen inom den första månaden, och det slutliga svaret kan lämnas under förlängningsperioden.
Begäran om borttagning — namngivna roller i granskningen
Skolkoll publicerar inte längre rektorsnamn som basuppgift på skolenhetssidor, i öppna datafiler, API/export eller strukturerad data. Detsamma gäller företrädarnamn ur årsredovisningsdata — styrelseledamot, revisor, firmatecknare och undertecknare. Personnamnsfälten tas ovillkorligt bort i den publika serveringsgränsen (namnfritt by design). Medan G5 är öppen är ny eller återkommande populationsvid intern namnbehandling pausad; befintliga namn får bara användas för dokumenterad datastädning, rättighetsärenden eller ett konkret, förhandsdokumenterat redaktionellt fall med egen prövning. Så begär du borttagning eller invänder mot behandlingen:
- Rektor: mejla info@skolspegeln.se med skolans skolenhetskod. Basvisningen innehåller inget rektorsnamn. Om ett namn trots det syns på en automatiserad publik yta på grund av ett fel, ange länken; vi tar bort felpubliceringen inom 14 dagar, utreder den brustna publiceringsgränsen och säkerställer att namnet inte återkommer genom den automatiska synkroniseringen. En begäran som gäller den icke-publika behandlingen hanteras enligt avsnitt 5.
- Styrelseledamot, revisor, firmatecknare eller undertecknare: mejla info@skolspegeln.se med huvudmannens organisationsnummer och din roll. För att identifiera rätt post kan vi även behöva ditt fullständiga namn eller en käll-/ärendereferens, även när begäran gäller en icke-publik behandling. Uppgifterna används endast så långt det behövs för identifieringen; ditt namn förs aldrig in i spärr- eller granskningsbeviset. Om begäran gäller en faktisk publicering, ange också var namnet syns (länk eller sidbeskrivning). Begäran kan registreras i förebyggande syfte, som spärr om publiceringsläget skulle ändras. Manuell process: vi bekräftar mottagandet inom 7 dagar. Vårt interna mål är att fatta det individuella beslutet och, om begäran beviljas, verkställa det inom 14 dagar. Information om vidtagna åtgärder lämnas utan onödigt dröjsmål och inom en månad från mottagandet (GDPR art. 12.3). Vid behov kan tiden förlängas med högst två ytterligare månader; då meddelar vi dig om förlängningen och skälen inom den första månaden, och det slutliga svaret kan lämnas under förlängningsperioden. Även här spärras en borttagen uppgift mot återkomst vid kommande inläsningar.
- Skolenhetens registrerade kontaktadress: mejla info@skolspegeln.se och ange adressen — den är identifieraren, och en spärr på adressen täcker samtliga skolenheter du svarar för. Adressen är den kontaktväg huvudmannen själv har anmält till Skolverkets register för publicering, och vi återger den som den står. Är den ställd i formen förnamn.efternamn@ pekar den däremot ut dig som fysisk person, och då prövas en invändning individuellt enligt avsnitt 5. Vid bifall undertrycks adressen på samtliga våra ytor och spärras mot återkomst vid kommande inläsningar. Har du skyddade personuppgifter, eller är du utsatt för hot eller våld i nära relation, verkställer vi undertryckningen omedelbart och prövar ärendet i efterhand — vi begär inga bevis och ber dig inte kontakta någon annan först.
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.
Om Skolkoll i ett konkret tillåtet fall behandlar dina personuppgifter med stöd av berättigat intresse (artikel 6.1 f) — däribland skolenhetens registrerade kontaktadress när den är ställd i formen förnamn.efternamn@, och nödvändig hantering av befintliga rektorsnamn eller företrädarroller inom den snäva G5-ramen i 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 även när den publika basvisningen är namnfri.
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@skolspegeln.se. Ange din roll och identifierare: adressen om invändningen gäller skolenhetens kontaktadress; skolenhetskod om du är rektor; huvudmannens organisationsnummer och din roll om du är styrelseledamot, revisor, firmatecknare eller undertecknare. För en icke-publik post kan vi dessutom behöva ditt fullständiga namn eller en käll-/ärendereferens för att identifiera rätt post. Namnet används endast för identifieringen och förs aldrig in i spärr- eller granskningsbeviset. Förekommer ditt namn på en faktisk yta, ange också var det syns (länk eller sidbeskrivning). Beskriv gärna de omständigheter du åberopar. Vi bekräftar mottagandet inom 7 dagar, prövar invändningen individuellt och dokumenterat, och har ett internt mål att besluta och, om invändningen godtas, verkställa åtgärden inom 14 dagar. Information om vidtagna åtgärder lämnas utan onödigt dröjsmål och inom en månad från mottagandet (artikel 12.3). Vid behov kan fristen förlängas med högst två ytterligare månader; då får du besked och skäl inom den första månaden, och det slutliga svaret kan lämnas under förlängningsperioden. Kan vi inte visa tvingande berättigade skäl upphör eller begränsas behandlingen och en eventuell faktisk namnpublicering tas bort. Den automatiska basvisningen förblir namnfri oavsett.
Vad vi väger in när invändningen gäller en kontaktadress. Uppgiften finns kvar i Skolverkets offentliga register även om vi undertrycker den hos oss, och den kan hämtas därifrån av vem som helst. Det verkningsfulla steget är därför rättelse vid källan — hos huvudmannen, som har anmält uppgiften, och i förekommande fall hos Skolverket. Har du redan begärt det väger vi in det: det visar att din situation är konkret och pågående, och det gör en undertryckning hos oss till en meningsfull överbryggning i väntan på rättelsen. Men det är ingen förutsättning för att vi ska pröva din invändning, och att du inte har gjort det kan aldrig ensamt bära ett avslag. Bevisbördan för ett avslag ligger på oss.
Vad en undertryckning inte når. Vi styr vår egen publicering framåt. Uppgiften kan finnas kvar i kopior som redan hämtats av andra, i sökmotorers cachar, i webbarkiv och i Skolverkets register. Vi lovar därför aldrig att en uppgift är borttagen från internet — bara att den inte längre publiceras av oss.
Ä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. Vår bedömning av rättsläget efter EU-domstolens dom i mål C-199/24 den 9 juli 2026 hålls aktuell genom löpande omprövning när ny praxis eller vägledning från IMY tillkommer, och denna sida uppdateras då.
6. Information enligt artikel 14 — namngivna roller i granskningen
Personuppgifter som hämtas från offentliga register omfattas normalt av informationskraven i artikel 14 GDPR. Medan DPIA-grind G5 är öppen är populationsvid behandling av namngivna personroller pausad. För det separata, åtkomstbegränsade råkällarkivet har källarkivbedömning v1.3 villkorat artikel 14.5 b-bedömningen: individuell information till hela kretsen skulle kräva att Skolkoll bygger den person- och kontaktkartläggning som dataminimeringen ska undvika. Den särskilda arkivraden nedan är publicerad skyddsinformation för detta flöde. Den 26 september 2026 verifierades den svenska och engelska informationen i produktion tillsammans med arkivets åtkomst-, lagrings- och gallringskontroller. Rutinmässig arkivering får ske inom denna avgränsning efter dokumenterad aktivering enligt källarkivbedömningen. Åtkomst- och gallringskontrollerna gäller fortlöpande; om ett startvillkor inte längre är uppfyllt ska nya rutinmässiga skrivningar stoppas. Om vi får konkret kännedom om en berörd person och en användbar kontaktväg lämnar vi direkt information inom artikel 14.3:s tidsgränser, om inget annat dokumenterat undantag gäller. Varje annan ny personrollsbehandling kräver en egen förhandsdokumenterad artikel 85- och artikel 14-prövning; annars lämnas individuell information senast inom en månad eller tidigare vid första kontakt eller utlämnande. Sidan kompletterar integritetspolicyn och publiceringspolicyn.
| Kategori av personuppgifter | Källa | Rättslig grund | Lagringstid / speglingslogik |
|---|---|---|---|
| Incidentella namn, yrkesroller, signaturer, arbetskontakt eller tjänsteadress, porträtt eller kort yrkesbiografi samt namngivna innehav, ersättningar eller närståendetransaktioner som redan ingår i oförändrade originalfiler av officiellt publicerade årsredovisningar eller ESEF-rapporter. Arkivet saknar OCR-/fulltext- och personindex; uppgifterna får inte skrivas till härledda lager. Material med uppgifter enligt artikel 9 eller 10 eller privat material omfattas inte av detta beslut. Om sådant material faktiskt upptäcks stoppas nya skrivningar och fortsatt användning; materialet raderas, om inte ett separat dokumenterat incident- eller rättsligt villkor kräver minsta möjliga åtkomstbegränsade bevarande. | Bolagsverket/HVD, ESEF-register och emittentens eller institutionens officiella publiceringskanal | Berättigat intresse (art. 6.1.f): att kunna verifiera proveniens och reproducerbarhet samt rätta tolkningen av namnfria finansiella uppgifter. Den snäva nödvändighets- och intresseavvägningen finns i källarkivbedömning v1.3. Artikel 14.5 b åberopas endast för detta avgränsade arkiv; om vi får konkret kännedom om en berörd person och en användbar kontaktväg lämnas direkt information enligt artikel 14.3 om inget annat dokumenterat undantag gäller. | En 30-dagars förvarning föregår åtkomstgranskning senast efter 12 månader, och materialet raderas när ändamålet upphör, normalt senast 24 månader efter hämtning. Repositoryt innehåller en daglig kontroll vars raderingsfönster ska dra av det liveavlästa soft-delete-fönstret, eller en konservativ planeringsfallback när livebevis saknas, samt en separat sjudygns fel-/retrybuffer. Kontrollen är sedan 2026-08-25 körd i produktion — första körningen är genomförd och inventeringsresultatet finns (10 230 objekt, 5 115 poster, noll förfallna). Det som fortfarande inte påstås är ett verkställt gallringsstickprov: ingenting var förfallet vid körningen, och ett sådant stickprov kan inte fabriceras utan får vänta på en verklig förfallen post eller en radering via rättighetsbegäran. Ett separat undantag måste beslutas och verkställas före det tidigare begäranfönstret. Samma beräkning används för det absoluta 36-månaderstaket. Begärans tid och den beräknade änden på soft-delete-fönstret redovisas separat; beräkningen påstås inte vara ett oberoende bevis på fysisk oåterställbarhet. Godkänd mottagar- och lagringsmålbild är Google Cloud i G-EU som personuppgiftsbiträde. Produktionsbucketen gs://skolkoll-data är sedan 2026-08-25 verifierad live för de fyra källarkivsprefixen: region EUROPE-WEST1, enhetlig bucketnivå-åtkomst och noll publika principaler, kontrollerat i den dagliga retentionkontrollen. Verifieringen omfattar källarkivet — readback för Firestore och Hosting-loggar är fortfarande väntande livebevis. Råkopior får inte lämnas ut publikt. Rättigheterna och kontaktvägen anges under tabellen. |
| Rektors namn, roll och skolenhet. Kan finnas i befintligt icke-publikt underlag men publiceras inte som basuppgift; ny eller återkommande populationsvid namnbehandling är pausad under G5 | Skolverkets register (öppna data) | Ingen positiv generell grund för populationsvid namnbehandling görs gällande medan G5 är öppen. Nödvändig datastädning och rättighetshantering bedöms inom sitt konkreta ändamål; en separat bearbetad granskningsyta kräver egen prövning av journalistiskt ändamål och publicering. Namnfria förändringshändelser omfattas inte av namnstoppet. | Ingen positiv identifierande populationsretention finns medan G5 är öppen. headMaster ignoreras vid den tidigaste mappergränsen och temporal backfill är namnfri. En framtida identifierande retention kräver ett separat positivt lager-för-lager-beslut och en driftsatt, verifierad purge-consumer med icke förlängande purgeAfter; ett senare observedAt får inte flytta fristen. Publik historik och förändringshändelser är namnfria. |
| Företrädarroller hos huvudmän — styrelseledamot, revisor, firmatecknare, undertecknare (namn + roll + huvudman). Kan finnas i befintligt icke-publikt underlag; namnen publiceras inte som basuppgift och ny eller återkommande populationsvid namnbehandling är pausad under G5 | Bolagsverket, offentliga årsredovisningar | Ingen positiv generell grund för populationsvid namnbehandling görs gällande medan G5 är öppen. Nödvändig datastädning och rättighetshantering bedöms inom sitt konkreta ändamål; ett konkret redaktionellt fall kräver en separat, förhandsdokumenterad prövning. | Ingen positiv identifierande populationsretention finns medan G5 är öppen. Ett femårstak från verifierad avregistrering blir endast ett framtida yttertak om G5 senare stängs med ett separat positivt behandlings- och gallringsbeslut och en driftsatt, verifierad purge-consumer med icke förlängande purgeAfter; ett senare observedAt får inte flytta fristen. Råkällans separata 12-/24-/36-månadersschema är inte Dataset D/E-retention. |
Kategorier som inte avsiktligt extraheras eller förs in i härledd Dataset D/E-projektion: personnummer, hemadresser, privata kontaktuppgifter, privatekonomi, familjerelationer utöver den formella rollen, signaturer eller känsliga kategorier enligt artikel 9. Signaturer och andra vanliga incidentella personuppgifter i en officiellt publicerad originalfil kan omfattas av den avgränsade arkivraden ovan. Uppgifter enligt artikel 9 eller 10 och privat material får inte användas vidare enligt arkivbeslut v1.3. Vid faktisk upptäckt stoppas nya skrivningar och fortsatt behandling, och materialet raderas om inte ett separat dokumenterat incident- eller rättsligt villkor kräver ett minimerat åtkomstbegränsat bevarande.
Personuppgiftsansvarig för denna behandling är Skolspegeln AB (org.nr 559359-7288), kontakt info@skolspegeln.se. (Biträdesrollen i avsnitt 1 gäller kommunlicens-data; för granskningsbehandlingen är Skolkoll personuppgiftsansvarig.)
Mottagare: godkänd mottagar- och lagringsmålbild för råkällarkivet är Google Cloud i G-EU som personuppgiftsbiträde. Produktionsbucketen gs://skolkoll-data är sedan 2026-08-25 verifierad live för de fyra källarkivsprefixen: region EUROPE-WEST1, enhetlig bucketnivå-åtkomst och noll publika principaler, kontrollerat i den dagliga retentionkontrollen. Verifieringen omfattar källarkivet — readback för Firestore och Hosting-loggar är fortfarande väntande livebevis. Råkopior får inte lämnas ut publikt. Varken rektorsnamn eller företrädarnamn ur årsredovisningsdata publiceras som basuppgift på skolkoll.se, i öppna datafiler, API/export eller strukturerad data; serveringslagret tar ovillkorligt bort personnamnsfälten. Namn kan förekomma i en separat redaktionell granskningsyta endast när en konkret granskning och egen publiceringsprövning 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. Blocket speglar rättsläget efter EU-domstolens dom i mål C-199/24 och uppdateras vid löpande omprövning när ny praxis eller vägledning från IMY tillkommer.
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 förkontrollerar hela dokumentet och skickar endast en kontaktminimerad leverantörskopia; kvarvarande risk är att klassificeringen ger ett falskt negativt resultat. Den risken och åtgärderna beskrivs i tabellen 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. |
| Dataläckage via tredjepartstjänst (Firebase, Stripe, Resend eller Zoho) | Låg × Hög | EU-regioner där verifierad tjänsteevidens finns; SCC för relevant tredjelandsbehandling; tjänstespecifik DPA/TIA och kvartalsvis underbiträdeskontroll. Minsta dataset och ändamålsseparering gäller: Stripe ser inga skoldata och Resend är begränsat till service-/bevakningsmail med 30 dagars leverantörsretention. Zoho Mail har inget positivt godkännande: nya användarinitierade inkommande förfrågningar får tas emot, manuellt bedömas och besvaras endast strikt nödvändigt efter ärendespecifik minimering och med ärendets dokumenterade grund; ingen AI används. Proaktiv/diskretionär kontakt, kampanj-/relationsbyggande, automation, bulk och nya integrationer/funktioner/datakategorier i Mail är STOPP. FAS-0-fristen 2026-08-14 passerade utan att konto-/DPA/SCC- och Indien-/USA-evidensen stängdes; endast den tillåtna minimerade mottagningen fortsätter, under pågående eskalering till en laglig ersättningskanal. Mail-restriktionen styr inte Campaigns. Campaigns fullständiga öppnings- och länkklicksspårning observerades på 2026-07-29; nästa utskick och utskicksförmögen automation är självständigt STOPP vid Z-CAMPAIGNS-grinden tills kontospecifik automation-, DPA/SCC-, avregistrerings-/RTBF-, retention-/suppression- och spårningsevidens är stängd och manuellt godkänd. Ingen tenant-teknisk verkställighet eller kapitel V-efterlevnad påstås. |
| Oavsiktligt återinförande eller felaktig publicering av namn på skolpersonal | Medel × Låg | Fail-closed namnprojektion för publika skolsidor, öppna datafiler, API/export och strukturerad data; automatiserade läckagetester samt borttagning av en eventuell felpublicering inom 14 dagar (avsnitt 4). En framtida namngiven publicering kräver ett separat dokumenterat releasebeslut. |
| 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. |
| En falsk negativ i Lane-D:s förkontroll medför att elevidentifierande eller känsligt sammanhang når OpenAI | Låg × Medel | Endast offentliga handlingar inom en godkänd, versionsmärkt kommun-/portal-/layoutström bearbetas. Före leverantörsanrop blockeras hela dokumentet vid privata källmarkörer, personnummer/elevidentifierande sammanhang eller indikatorer på artikel 9/10-uppgifter; e-post och telefon tas bort ur leverantörskopian. Det lokala originalet används endast för grundning. OpenAI DPA och tillämplig överföringsmekanism gäller. /v1/chat/completions används med store: false, vilket enligt den 2026-07-29 kontrollerade leverantörsdokumentationen innebär att inget response application state skapas men tillåter prompt-cache med krypterade KV-tensorer i GPU-lokal lagring i upp till 24 timmar. Standardiserade missbruksövervakningsloggar kan behållas i upp till 30 dagar och säkerhets-/rättsliga undantag kan kräva längre bevarande. Detta är minimering med uttryckliga undantag, inte ZDR. Klassificerare är inte ofelbara; kandidater maskeras, ingen automatisk publicering sker och alla kandidater passerar en människogranskad kö. |
8. Personuppgiftsincident
Vid misstänkt personuppgiftsincident:
- När Skolkoll är personuppgiftsbiträde i kommunlicensens P1–P3-kedja underrättar vi den avtalade personuppgiftsansvariga utan onödigt dröjsmål, med ett internt mål om en första faktabaserad avisering inom 24 timmar, och lämnar därefter löpande kompletteringar. Kommunen bedömer och ansvarar för eventuell anmälan enligt artikel 33 och information enligt artikel 34.
- När Skolkoll är personuppgiftsansvarig bedömer vi risken och anmäler till IMY utan onödigt dröjsmål och, om möjligt, senast 72 timmar efter att vi fått vetskap om incidenten när den sannolikt medför risk för enskildas rättigheter och friheter. Vid sannolik hög risk informerar vi även de berörda personerna utan onödigt dröjsmål enligt artikel 34.
- 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-målbild: repositorykonfigurationen anger
europe-west1(Belgien) för Firestore, Cloud Functions och Cloud Storage; arkiverad produktionsreadback 2026-09-05 styrker Firestore ieurope-west1och samtliga åtta produktionsbuckets iEUROPE-WEST1eller EU-multiregion. Stripe-betalningar behandlas primärt i Irland. Domänrouting för Zoho Mail/Campaigns och konfigurerade endpoints för Desk/CRM pekar mot Zohos EU-tjänster, men routing bevisar inte Mail/Campaigns-tenantens faktiska kontoregion. Firebase Hosting använder ett globalt CDN och omfattas därför inte av målbilden för regional lagring. - USA/tredjeland: Firebase Hosting och Authentication samt leverantörsåtkomst kan medföra behandling utanför EU/EES. Resend levererar via USA. Zoho-support från Indien och tillämpliga USA-underbiträden, Sentry-support från USA-team, Anthropic/OpenAI-anrop och social-login-leverantörer kan också innebära tredjelandsbehandling.
För tredjelandsöverföring tillämpas följande rättsliga mekanismer:
- Standard Contractual Clauses (SCC) — används enligt EU-kommissionens beslut 2021/914 när relevant leverantörs- och kontoavtal omfattar tredjelandsbehandlingen. Zoho publicerar DPA/SCC-villkor. Ett kontospecifikt biträdesavtal tecknades med Zoho Corporation B.V. 2026-09-11; enligt dess klausul 10 ersätter det parternas tidigare dataskyddsavtal på kontonivå. Det avtalet är artikel 28-biträdesklausulerna, inte kapitel V-klausulerna. För Mails Indien-led identifierar Zoho Legals svar 2026-09-08 SCC Modul 3 i löpande text, men mekanismen är fortfarande leverantörsuppgiven snarare än avtalad och Indien-/USA-bedömningarna är öppna. För Campaigns täcker det avtalet artikel 28-inkorporeringen; kapitel V-mekanismen är fortsatt leverantörsuppgiven snarare än avtalad, bakom en separat pre-send-grind. Mail har inget positivt godkännande.
- EU-US Data Privacy Framework (DPF) — alternativ rättslig grund för leverantörer som är DPF-certifierade (Google, Stripe).
Schrems II-konsekvenser bedöms per leverantör och scenario i den interna överföringsbilagan v2.9. Zoho Mails konto-/avtalsinkorporering och fokuserade Indien-/USA-bedömning skulle stängas av FAS-0 senast 2026-08-14. Fristen passerade. Zoho Legal har därefter identifierat SCC Modul 3 för Indien-ledet i löpande text. Det kontospecifika DPA:t signerades 2026-09-11, men dess Schedule 1 är standardavtalsklausulerna för artikel 28.3–28.4 och anger själv i clause 1(f) att de inte i sig säkerställer efterlevnad av kapitel V, så överföringsmekanismen är fortfarande leverantörsuppgiven snarare än avtalad. Bedömningen enligt nu gällande indisk rätt och den fokuserade USA-bedömningen är fortsatt öppna: avtalets Schedule 2 upptar enbart Indien som koncernbolag med åtkomst till EES-kunders uppgifter, medan leverantörens egna SOC 1, SOC 2 och ISO-lokalbilagor anger Austin i USA som driftsort för support. Fallbacken är därför fortsatt det gällande läget: den daterade interimistiska riskrestriktionen utan positivt godkännande kvarstår, och endast minimerad rättsligt nödvändig mottagning sker under pågående eskalering till en laglig ersättningskanal. Campaigns är utsedd plattform, men nästa utskick och utskicksförmögen automation är STOPP tills dess separata kontospecifika evidensgrind är fullständigt stängd och manuellt godkänd. Kommunlicens-kunder kan begära ett relevant utdrag.
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: Point-in-Time Recovery (PITR) är målbilden för Firestore och ger, när funktionen är aktiverad, tidpunktsåterställning inom det fönster Google Cloud tillhandahåller (upp till 7 dagar). Faktisk PITR-status och eventuella schemalagda backup-exporter i produktion är inte styrkta genom arkiverad readback i denna revision. Releasegrinden kräver
gcloud firestore databases describerespektivegcloud firestore backups schedules listinnan de får beskrivas som aktiva. Å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. Bilagan är godkänd för användning i upphandlingssvar genom dokumenterat beslut den 8 augusti 2026. Godkännandet omfattar inte de poster som är märkta som öppna ägarinput i säkerhetsbilagans egen överlämningschecklista. Sedan 25 augusti 2026 är bedömningen enligt cybersäkerhetslagen genomförd och daterad, och en backup-auktoritet är utsedd. Fortfarande öppna är supporttier-/SLA-beroenden, kall-återställningstest, samt återstående TOM- och leverantörsbevis. För backup-auktoriteten gäller att hon är utsedd med fungerande åtkomst, men vägen är oprövad: hon har egen andra faktor på tjänstkontona sedan 2026-08-26, men ingen registrerad och testad out-of-hours-kanal finns, och åtkomsten går via delat lösenordsvalv — vilket innebär att åtgärder loggas under underhållarens identitet och inte kan återkallas separat. Säkerhetsbilagans egen överlämningschecklista är den auktoritativa och fullständiga listan; uppräkningen här är en sammanfattning. Ingen av posterna får anges som utfästelse.
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