Säkerhet och datahantering
Kontrollera säkerhetsstatus, dataplats, underbiträden, incidentprocess och DPA-underlag.
Snabbkoll
Region, kryptering, secrets, SSO, audit-loggar, incidentrutiner och avtalsdokumentation.
Repositorykontroller är verifierade, och produktionsregionen är styrkt genom arkiverad readback; secrets, PITR och övrig livekonfiguration kräver fortfarande separat readback före release. Extern pentest och formell certifiering är inte genomförda.
Statusen skiljer mellan verifierad repositorykonfiguration, leverantörsdokumentation och väntande produktionsbevis.
Datacenter och kryptering
Plats
Repositoryt konfigurerar Cloud Functions för Google Clouds regioneurope-west1 (Belgien, EU), och samma region är målbild för Cloud Storage och Firestore. Produktionsregionen ärstyrkt genom arkiverad readback 2026-09-05: Firestore(default) ligger på europe-west1 och samtliga åtta produktionsbuckets på EUROPE-WEST1 eller EU-multiregion. Firebase Hosting levereras via ett globalt CDN och har därför inte samma regionala avgränsning. Firebase Authentication omfattas av Google Cloud DPA/SCC/DPF. Readbacken omfattar region — inte PITR, retention eller secrets, som fortsatt redovisas var för sig nedan.
Vissa personuppgiftsbiträden, underbiträden och externa tjänster (Stripe, Anthropic, OpenAI, Google Analytics 4 och sociala inloggningsleverantörer) kan behandla data utanför EU/EES. Beroende på mottagarland och mottagare tillämpas adekvansbeslut, DPF eller EU:s standardavtalsklausuler (SCC) tillsammans med respektive leverantörs DPA. Zoho PageSense laddas via EU-scriptet 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. Separata Zoho Desk-support- och CRM-leadytor är konfigurerade men STOPP och får inga nya uppgifter innan sina flödesspecifika grindar har passerats. De nuvarande journalistanslutningarna Z-DESK och Z-CRM är däremot permanent kodstoppade oavsett generell leverantörsevidens eller konfigurationsflaggor: Desk-kontakten saknar ärendelivscykel och CRM-kontakten använder global e-postdeduplicering. Fullständigt beställningsinnehåll får inte användas som reservväg. En framtida ersättare måste vara beställningsbunden och ha testad minimering och radering. Zoho Mail har däremot 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 innehålls- och nödvändighetsminimering under den daterade interimistiska riskrestriktionen; innehållet skickas inte till AI. FAS-0-fristen 2026-08-14 för konto-/DPA/SCC- och Indien-/USA-evidensen passerade utan att evidensen stängdes, och eskaleringen pågår; valfria/nya ändamål, integrationer, funktioner, datakategorier, bulkflöden och diskretionära C3-/journalistutskick är STOPP. Repositoryts CSP tillåter Sentrys tyska ingest-origin, men produktions-DSN och eventregion är inte verifierade genom live-readback; ingen positiv live-region påstås. Se tabellenunderbiträden och externa tjänster nedan för fullständig översikt, och Dataskydd och underbiträden för operativa detaljer.
Kryptering i vila (encryption-at-rest)
Firestore och Cloud Storage krypterar all data i vila med Google-hanterade nycklar (AES-256) som standard. Vi använder inte kundhanterade krypteringsnycklar (CMEK) i dagsläget — det är en funktion vi utvärderar inför framtida Pro-tier-åtaganden.
Kryptering under transport (in-transit)
All trafik till och från Skolkoll sker via TLS 1.2 eller senare. Firebase Hosting aktiverar HSTS (HTTP Strict Transport Security) automatiskt, vilket förhindrar nedgradering till okrypterad HTTP. Certifikat hanteras automatiskt av Google och förnyas utan manuell åtgärd.
Secrets och autentisering
Secrets Management
Alla hemligheter — inklusive ADMIN_TOKEN, STRIPE_SECRET_KEYoch STRIPE_WEBHOOK_SECRET — deklareras somFirebase Secret Manager-bindningar i Cloud Functions-koden (via secrets: […] i functions-options och defineSecret()). Inga hemligheter finns hårdkodade i källkod eller miljöfiler. Cloud Functions v2 läser värdena från Google Cloud Secret Manager vid runtime. Releasegrinden kräver att aktiva secret-versioner för varje deklarerad hemlighet verifieras medgcloud secrets versions list. Denna revision innehåller inte en arkiverad produktionsreadback och påstår därför inte att alla aktiva versioner redan har verifierats.
ID-token revocation
Skyddade admin-endpoints använder två uttryckliga modeller. Firebase-ID-tokenbaserade endpoints verifierar token medcheckRevoked: true; lösenordsbyte eller manuell revokering kan då ogiltigförklara sessionen före token-expiry. Separata operativa endpoints använder i stället den roterade X-Admin-Token-hemligheten och omfattas inte av Firebase-tokenrevokering.
Admin-åtkomst
Admin-token roteras manuellt och lagras aldrig i klientkod. Admin-endpoints kräver HTTP-headern X-Admin-Token med korrekt värde, kontrollerat server-side. Inga admin-operationer är tillgängliga från webbläsaren utan explicit autentisering.
Kommunlicens SSO
Kommunlicens använder Firebase Authentication som kontolager. Standardflödet är e-postbaserad inloggning och organisationsinbjudningar. För kommuner som kräver central identitetshantering kan SAML 2.0 eller OIDC aktiveras som Enterprise SSO-tillägg.
- IdP-spår: SAML 2.0 eller OIDC, inklusive Microsoft Entra ID/Azure AD.
- Rollmappning: Kommunens IdP styr identiteten; Skolkoll lagrar roll och organisationstillhörighet för behörighet i tjänsten.
- Avslut: När kommunen tar bort användaren i sin IdP upphör ny inloggning. Befintliga Firebase-sessioner kan revokeras manuellt vid behov.
- Start: Metadata-utbyte, testkonto och domänverifiering krävs före produktionsstart.
Se även SSO-status i upphandlingspaketet.
Audit logging
Känsliga administratörsoperationer loggas i Firestore-kollektionen auditLog. Kollektionen har deny-all Firestore Security Rules — ingen klient kan läsa eller skriva till den. Åtkomst sker uteslutande via Firebase Admin SDK (server-side), vilket eliminerar risken för manipulation via klientkod.
Varje audit-loggpost innehåller: tidsstämpel, operation, utförande identitet och påverkat objekt. Nya poster taggas med expiresAt för 2 års retention och raderas asynkront av Firestores TTL-mekanism. Live-readback 2026-07-30 visade att auditLog.expiresAt-policyn är ACTIVE; detta bevisar policystatus, inte att ett visst utgånget stickprov har raderats.
För varje berättigad behandlad Kollen-chattförfrågan gör servern högst ett asynkront skrivförsök till en separat post. Svaret väntar inte på skrivningen, fel loggas och lagring kan därför inte garanteras. Posten använder en nycklad, domänseparerad HMAC-SHA-256-pseudonym av IP-adressen som kortas till 16 hexadecimala tecken samt längd på fråga/svar och kontext som exakt åttasiffrig skolenhetskod eller null — aldrig fråge- eller svarsinnehåll. Pseudonymisering sker vid skrivning; raderingsrutinen för dessa poster dokumenteras i Dataskydd och underbiträden.
Backup och återställning
Point-in-Time Recovery (PITR) är målbilden för Firestore-databasen. När PITR är aktiverad möjliggör Google Cloud tidpunktsåterställning inom det fönster tjänsten tillhandahåller (upp till 7 dagar). Faktisk PITR-status och retention i produktion är inte styrkta genom arkiverad readback i denna revision. Releasegrinden krävergcloud firestore databases describe innan PITR får beskrivas som aktivt. Å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.
Underbiträden och externa tjänster
Nedanstående lista blandar faktiska personuppgiftsbiträden/underbiträden med externa datakällor och API:er som inte alltid behandlar personuppgifter på Skolkolls uppdrag. Den bindande underbiträdeslistan för PuB/DPA-syfte finns påDataskydd och underbiträden.
| Tjänst | Roll / funktion | Plats | GDPR-roll / grund |
|---|---|---|---|
| Firebase / Google Cloud | Hosting, databas (Firestore), Cloud Functions, Secret Manager, Cloud Storage | Repositoryt konfigurerar Cloud Functions för europe-west1 (Belgien). Firestore ligger på europe-west1 och samtliga produktionsbuckets på EUROPE-WEST1 eller EU-multiregion, styrkt genom arkiverad readback 2026-09-05. Firebase Hosting: globalt CDN. Firebase Authentication omfattas av Google Cloud DPA/SCC/DPF. | Avtal (art. 6.1.b); DPA med Google ingår i Firebase-villkoren |
| Stripe | Betalningshantering för Pro-tjänster; kortuppgifter hanteras aldrig av Skolkoll | Irland (EU) primärt; vissa fraud-detection-funktioner kan involvera Stripe US under SCC | Avtal (art. 6.1.b); Stripes DPA; SCC där det behövs |
| Google Analytics 4 (GA4) | Anonym besöksstatistik; laddas bara efter samtycke | USA | Samtycke (art. 6.1.a); SCC; IP-anonymisering aktiverad |
| Zoho PageSense | Webbanalys, A/B-testning och heatmaps/session recording på publika sidor; laddas bara efter samtycke | EU-script via cdn-eu.pagesense.io; kontoinkorporering, live tenantregion/plan och fokuserad överföringsnot är ännu inte verifierade och ingår i kvartalskontrollen | Samtycke (art. 6.1.a); Zoho publicerar standardiserade DPA/SCC-villkor, inte ett verifierat kontoresultat |
| Zoho Desk | Den separata supportytan är konfigurerad men STOPP före flödesspecifik aktivering. Den nuvarande journalistanslutningen Z-DESK är permanent kodstoppad oavsett generell evidens eller flaggor eftersom kontakten saknar ärendelivscykel. Ingen fullständig beställningsfritext får användas som reservväg; en framtida ersättare måste vara beställningsbunden med testad minimering och radering | Zoho publicerar en EU-hostad Desk-endpoint och standardiserade DPA/SCC-villkor; kontoinkorporering, live tenantregion/plan och fokuserad överföringsnot är ännu inte verifierade och ingår i kvartalskontrollen | För en användarinitierad förfrågan i Skolspegelns eget supportflöde används art. 6.1.b endast när den registrerade själv är den blivande avtalsparten och begär föravtalsåtgärder; annars dokumenterad art. 6.1.f för nödvändig manuell mottagning, ärendespecifik minimering och svar. Oväntade tredjeparts- eller artikel 9-/10-uppgifter kräver separat grund/villkor eller behandlas inte vidare. I Kommunlicens-P1 är kommunen personuppgiftsansvarig och Skolkoll biträde enligt instruktion. Publicerade Zoho-villkor är inte kontoinkorporeringsbevis; journalist-Z-DESK förblir kodstoppad |
| Zoho CRM | Den separata leadytan är konfigurerad för minimerade strukturerade fält men STOPP före flödesspecifik aktivering. Den nuvarande journalistanslutningen Z-CRM är permanent kodstoppad oavsett generell evidens eller flaggor eftersom den använder global e-postdeduplicering. Ingen fullständig beställningsfritext eller Description får användas som reservväg; en framtida ersättare måste vara beställningsbunden med testad minimering och radering | Zoho publicerar en EU API-endpoint och standardiserade DPA/SCC-villkor; kontoinkorporering, live tenantregion/plan och fokuserad överföringsnot är ännu inte verifierade och ingår i kvartalskontrollen | För en användarinitierad lead-/demoförfrågan används art. 6.1.b endast när den registrerade själv är den blivande avtalsparten och begär föravtalsåtgärder; annars dokumenterad art. 6.1.f för nödvändig manuell mottagning, ärendespecifik minimering, svar, missbruksskydd och operativ återställning. Oväntade tredjeparts- eller artikel 9-/10-uppgifter kräver separat grund/villkor eller behandlas inte vidare. Separat marknadsföringssamtycke gäller endast det ändamålet. Journalistformulärets lagring, beställningshantering och kontaktsvar bygger i stället på formulärsamtycket; art. 6.1.f gäller där endast missbruksskydd och operativ återställning, inte CRM-ändamålet. Publicerade Zoho-villkor är inte kontoinkorporeringsbevis; journalist-Z-CRM förblir kodstoppad |
| Zoho Mail | Daterad interimistisk riskrestriktion utan 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 innehålls-, nödvändighets- och minimeringsbedömning; ingen AI. Proaktiv/diskretionär kontakt, kampanj-/relationsutskick, automation, bulk samt nya integrationer, funktioner eller datakategorier i Mail är STOPP. FAS-0-fristen 2026-08-14 passerad; endast minimerad inkommande mottagning fortsätter, under pågående eskalering till en laglig ersättningskanal. Campaigns styrs separat av sin egen Z-CAMPAIGNS-grind | Zoho One; kontospecifikt artikel 28-biträdesavtal tecknat 2026-09-11, men kapitel V-mekanismen är leverantörsuppgiven och den fokuserade Indien-/USA-bedömningen är inte gjord. Export, minimering och verifierad radering är tillåtna; ingen kapitel V- eller tenant-teknisk efterlevnad påstås | Art. 6.1.c där en särskild skyldighet gäller. Art. 6.1.b används bara om den registrerade själv är möjlig avtalspart; annars dokumenterad art. 6.1.f begränsad till att läsa, minimera och besvara den användarinitierade förfrågan. Fritext antas inte vara offentlig; artikel 9-/10-uppgifter kräver separat grund eller behandlas inte vidare |
| Sentry | Felövervakning; samlar in felmeddelanden, stacktraces, webbläsar-/OS-information och IP-adress som anonymiseras kort efter mottagandet | Repositoryts CSP tillåter ingest.de.sentry.io i Tyskland; produktions-DSN och eventregion är väntande livebevis, så ingen positiv live-region påstås. SCC gäller för eventuell support från USA-teamet. | Berättigat intresse (art. 6.1.f); Sentry DPA; SCC för eventuell supportåtkomst från USA |
| Anthropic (Claude API) | Avsett direkt personuppgiftsbiträde för AI-assistenten Kollen. ANTH-API omfattas av ett juridiskt landevidensstopp; repositoryt innehåller en fail-closed gate, men produktionsdeploy och live-readback är väntande och någon aktiv produktionsspärr påstås inte vara verifierad | API-data lagras i USA; leverantören anger även utvalda behandlingsplatser i Europa, Asien och Australien utan en fullständig landlista. Inget annat land utanför EES är godkänt i nuläget. | Berättigat intresse (art. 6.1.f) enligt Kollen-LIA v1.3, men ANTH-API är stoppad tills landevidensen uppfyller överföringsbilagans exakta, godkända allowlist-kontrakt ["US"] och varje faktisk mottagare är täckt av adekvans, DPF eller SCC med land- och mottagarspecifik TIA. Anthropics DPA gäller; inget generellt ZDR-avtal krävs. API-innehåll raderas normalt inom 30 dagar; flaggat innehåll kan sparas i upp till 2 år och trust-and-safety-klassificeringar i upp till 7 år, eller längre när lag kräver det. |
| OpenAI | Chalkboard-stilisering av skolbilder under OpenAI:s säkerhets-/innehållspolicyer: insända bilder efter uttryckligt samtycke, eller separat importerade licensierade bilder efter en positiv redaktionell kontroll av rättigheterna och att inga identifierbara personer finns. Det finns inget separat modereringsändamål eller extra modellanrop. Kontaktuppgifter, fotografnamn, rättighetsinnehavare, källänkar, fotodatum och fritext skickas inte till OpenAI. | EU samt tillämpliga tredjeländer enligt den aktuella överföringsbilagan, däribland USA | Samtycke (art. 6.1.a) för insända bilders AI-val; berättigat intresse (art. 6.1.f) för rättighetskontrollerade importerade bilder och nödvändig proveniens; OpenAI DPA; adekvansbeslut, DPF eller SCC beroende på mottagarland. Chalk-stilisering av rättighetskontrollerade bilder utan identifierbara personer kräver inte ett generellt ZDR-avtal. |
| Resend | E-postleverans för skolbevakning och transaktionsmail | USA | Berättigat intresse / samtycke (art. 6.1.f/a); SCC |
| Nominatim (OpenStreetMap) | Två avgränsade geokodningsflöden. Repositoryt implementerar just-in-time-instruktion, blockering av gata-/hemadressmarkörer, nummer, kontaktuppgifter och oklar personliknande flerordsfritext samt en separat minimeringsgrind för batchflödet. Kontrollen minskar risken men bevisar inte att varje tillåten kort enordsfråga saknar personuppgifter. Produktionsdeploy och live-readback är väntande. Webbläsarens geolokalisering påverkas inte och använder inte Nominatim. | OSMF:s publika Nominatim-tjänst är extern mottagare. Leverantörens faktiska råloggsländer och råloggsretention är ännu inte slutna. Repositorymålet är klientcache i sessionStorage med högst 20 poster och 24 timmar samt batchcache i en egen GCS-bucket med högst 365 dagar. Aktiv produktionscache, bucketregion och gallringsreadback är inte verifierade. | Berättigat intresse (art. 6.1.f), men båda flödena är rättsligt stoppade för nya externa anrop tills respektive operativ bedömning godkänts. Repositoryt gör grindarna standardmässigt avstängda, med minst 1,1 sekunder mellan klientanrop och en global enkeltrådad batchkö med minst 15 sekunder mellan starter när batchgrinden uttryckligen öppnas. Produktionsdeploy och live-readback är väntande; någon aktiv produktionsspärr påstås inte vara verifierad. |
| ResRobot (Trafiklab) | Kollektivtrafikdata för pendlingsflik; koordinater proxas via Skolkolls server | Sverige (EU) | Berättigat intresse (art. 6.1.f) |
| JobTech (JobEd Connect) | Användarinitierad yrkesmatchning när karriärfliken öppnas. Endast hårdkodade programnyckelord eller offentligt programnamn skickas; mottagaren får även besökarens IP- och requestmetadata. Ingen fri användartext skickas. | Den rättsliga direkta mottagaren är den svenska myndigheten Arbetsförmedlingen. north_europe är endast tjänstens konfigurerade regionetikett och bevisar inte ett fysiskt behandlings- eller åtkomstland. | Berättigat intresse (art. 6.1.f), Arbetsförmedlingen behandlas som självständig personuppgiftsansvarig för mottagandet och ansvarar i den rollen för eventuell senare leverantörsbehandling. Flödet är godkänt endast i denna avgränsning; ändrad roll, fri persontext eller ändrad direkt mottagare stoppar flödet för ny bedömning. JobEd-specifik råloggsretention följs upp årligen. |
| Skolverkets API | Offentlig skolkälla. Själva detaljförfrågan skickar endast skolenhetskod och inget personfält. Källsvaret kan beroende på endpoint innehålla personuppgifter, bland annat headMaster; medan G5 är öppen och personrollsbehandlingen är STOPP kasseras fältet vid den tidigaste mappergränsen och får inte lagras, indexeras, materialiseras eller tas med i historik. | Sverige (EU) | Offentlig källstatus gör inte namn till icke-personuppgifter. Nuvarande behandling är begränsad till namnfria skoluppgifter; äldre namn får endast hanteras för dokumenterad städning och rättighetshantering. Ett framtida personrollsflöde kräver separat beslut och öppnar inte genom källåtkomsten. |
Incidentrespons
Vi är ett litet team och vill vara ärliga om vår process: vi har inte ett formellt Security Operations Center (SOC) eller 24/7-beredskap. Vad vi har är en definierad process som vi följer konsekvent.
- Övervakning och detektion: Repositoryts Sentry-integration är avsedd att fånga applikationsfel i realtid när en verifierad produktions-DSN är aktiv; denna revision påstår inte att live-mottagning har verifierats. Google Cloud-konsolen har alerting på ovanliga CPU-toppar, quota-överskridanden och auth-fel. Sentry-dashboard granskas enligt driftrutinen när integrationen är aktiv.
- Triage (inom 24 timmar): När en möjlig säkerhetsincident detekteras gör ansvarig utvecklare en initial klassificering: påverkar incidenten personuppgifter? Är tjänsten otillgänglig? Finns tecken på obehörig åtkomst?
- Inneslutning och mitigering: Beroende på incidenttyp vidtas omedelbara åtgärder — revokering av komprometterade tokens, spärr av misstänkta IP-adresser, eller tillfällig nedstängning av berörd funktion.
- Notifiering: För behandling där Skolspegeln är personuppgiftsansvarig anmäler vi till Integritetsskyddsmyndigheten (IMY) utan onödigt dröjsmål och, om möjligt, inom 72 timmar endast när incidenten sannolikt medför risk för registrerades rättigheter och friheter (GDPR art. 33.1). Drabbade registrerade kontaktas när risken sannolikt är hög (art. 34). När Skolspegeln är personuppgiftsbiträde underrättar vi i stället den namngivna personuppgiftsansvariga utan onödigt dröjsmål enligt art. 33.2 och bistår dennes bedömning. Notifiering sker via info@skolspegeln.se.
- Återställning: Statiska sidor byggs om från källdata. Firestores PITR får användas för databaspåverkan först när live-statusen har verifierats och ett kontrollerat återställningstest har godkänts. Fram till dess lovar denna sida ingen PITR-baserad återställning; incidentledaren använder den faktiskt verifierade backup-/källåterbyggnadsväg som är tillgänglig.
- Post-incident review: Efter varje allvarlig incident dokumenterar vi rotorsak, åtgärder och förebyggande ändringar internt. Väsentliga säkerhetsförbättringar kommuniceras i releaseloggen.
Driftstatus och planerat underhåll publiceras på driftsstatussidan.
Compliance och certifieringar
| Standard / krav | Status | Kommentar |
|---|---|---|
| GDPR | Underlag finns | Integritetspolicy, samtyckesbanner, PuB-mall, ROPA, underbiträdesregister och raderingsrutiner är dokumenterade. Kommunalt signeringspaket (PuB, säkerhetsbilaga, kontinuitetssvar) är godkänt för användning genom dokumenterat beslut den 8 augusti 2026. Godkännandet omfattar inte de poster som är märkta som öppna ägarinput i underlagen — de får inte anges som utfästelser. |
| SOC 2 Type II | Ej certifierat | Vi följer SOC 2-principerna (säkerhet, tillgänglighet, konfidentialitet) men har inte genomgått en formell Type II-revision. Certifiering utvärderas inför storskalig kommunlansering. |
| ISO 27001 | Ej certifierat | ISO 27001-certifiering är inte genomförd. Vi arbetar strukturerat med informationssäkerhet men utan formell ISMS-implementation. |
| Extern penetrationstest | Ej genomförd | Ingen extern säkerhetsrevision av applikationen har genomförts under 2026. En extern pentest är planerad inför produktionslansering av public free-tier API. |
| PCI DSS | Via Stripe | Skolkoll hanterar inga kortuppgifter direkt. Stripe, som är PCI DSS Level 1-certifierat, hanterar all kortdata. |
Responsible disclosure
Om du upptäcker en säkerhetsbrist i Skolkoll uppskattar vi att du rapporterar den till oss innan du publicerar den offentligt. Vi åtar oss att:
- Bekräfta mottagning av din rapport inom 5 arbetsdagar.
- Hålla dig informerad om utredningens progress.
- Åtgärda bekräftade säkerhetsbrister inom rimlig tid beroende på allvarlighetsgrad.
- Erkänna ditt bidrag i releaseloggen om du önskar det (med ditt samtycke).
Vi erbjuder ingen ekonomisk belöning (bug bounty) i dagsläget, men vi tar alla rapporter på allvar och kommunicerar öppet om utredningens resultat.
Disclosure-policy: Vi tillämpar en 90-dagars koordinerad disclosure-period. Om en brist inte åtgärdats inom 90 dagar från din rapport förbehåller du dig rätten att publicera detaljerna. Vi kommunicerar proaktivt om vi behöver mer tid.
Kontakt: Skicka din rapport tillinfo@skolspegeln.se med ämnesraden "Security disclosure". Inkludera reproduktionssteg och bedömning av påverkan. Kryptera gärna med vår offentliga nyckel om du hanterar känslig information — kontakta oss så delar vi den.
Vänligen rapportera inte via GitHub Issues eller sociala medier.
DPA och avtalsdokumentation
Skolkoll fungerar som personuppgiftsbiträde för kommuner och skolor när vi behandlar personuppgifter för deras räkning inom Enterprise eller andra betalda tjänster. Vi tillhandahåller ett personuppgiftsbiträdesavtal (PuB-avtal / DPA) anpassat för kommunal upphandling.
- Standardmall: Se vår PuB-mall för ett färdigt biträdesavtal.
- Anpassat avtal: Kontakta info@skolspegeln.se om din organisation kräver ett skräddarsytt DPA.
- ROPA (Register of Processing Activities): Tillgänglig på ropa-sidan.
- Dataskyddsdetaljer: Se dataskydds- och underbiträdessidan för operativa GDPR-detaljer.
- Säkerhetsbilaga: En källhänvisad bilaga för kommunal säkerhetsgranskning (release-grind, stage/prod-isolering, byggintegritet, säkerhetsheaders) lämnas 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 överlämningschecklista, som är den fullständiga listan.
Se även: Integritetspolicy · SLA och driftnivå · Kommersiell separation · Transparens