Kraven i katalogen gäller generellt för alla lösningar som hanterar K3-klassad information och som används av vård- och omsorgsförvaltningen (VOF) och individ- och arbetsmarknadsförvaltningen (IAF) — till exempel avvikelsehantering, ekonomiskt bistånd och andra verksamhetssystem.
Varje krav är märkt med vad det påverkar och hur. Rutiner och styrning anges med räckvidd: team = inom utvecklingsteamet, org = utanför teamet (verksamhet, IT-drift, säkerhetsfunktion), team+org = både och.
✓ Uppfyllt · ✗ Ej uppfyllt · Delvis Delvis uppfyllt · Oklart Behöver utredas · N/A Ej tillämpligt · tomt = ännu inte bedömt. Kolumnen Kommentar innehåller teamets anteckningar om status och kvarstående arbete.
Kraven i katalogen hänvisar till ett antal lagar, föreskrifter och modeller. Här är en kort orientering om vad de är.
Ställer krav på systematiskt och riskbaserat cybersäkerhetsarbete hos bland annat kommuner — inklusive säkerhet vid förvärv, utveckling och underhåll av system. Betydande incidenter ska tidigt rapporteras: en första varning inom 24 timmar och en incidentanmälan normalt inom 72 timmar.
Föreskrifter som konkretiserar cybersäkerhetslagens krav i praktiska säkerhetsåtgärder — informationsklassning, behörighetsstyrning, loggning, kryptering, separation av miljöer med mera. Paragrafhänvisningarna i kravkatalogen (t.ex. 4 kap. 21 §) pekar hit.
Reglerar all behandling av personuppgifter. Artikel 32 kräver riskanpassade säkerhetsåtgärder — till exempel pseudonymisering och kryptering — och personuppgiftsincidenter ska anmälas till Integritetsskyddsmyndigheten inom 72 timmar. När en leverantör behandlar personuppgifter för kommunens räkning krävs personuppgiftsbiträdesavtal (PuB-avtal).
Reglerar vilka uppgifter i offentlig verksamhet som omfattas av sekretess — till exempel uppgifter om enskildas hälsa och personliga förhållanden inom vård och omsorg. 10 kap. 2 a § styr när sekretessbelagda uppgifter får lämnas ut till en aktör som endast tekniskt bearbetar eller lagrar dem, till exempel en molnleverantör.
Kräver att vårdgivaren bedriver systematiskt patientsäkerhetsarbete: händelser som medfört eller kunnat medföra vårdskada ska utredas, allvarliga vårdskador anmälas till IVO (lex Maria) och en patientsäkerhetsberättelse upprättas årligen. Avvikelsehanteringen är ett direkt verktyg för dessa skyldigheter — anmälningsspåret till IVO löper parallellt med incidentrapporteringen enligt cybersäkerhetslagen och GDPR.
Ramlag som kräver att vårdens kvalitet systematiskt och fortlöpande utvecklas och säkras (5 kap. 4 §). Kravet konkretiseras i Socialstyrelsens föreskrifter om ledningssystem för systematiskt kvalitetsarbete (SOSFS 2011:9), där avvikelsehantering, riskanalyser och egenkontroll är obligatoriska delar. HSL ställer få egna tekniska krav men gör avvikelseprocessen i sig till en författningsreglerad process.
Reglerar behandling av personuppgifter inom hälso- och sjukvården — även för kvalitetssäkring, inte bara journalföring. Kräver behörighetsstyrning efter behov (inre sekretess), åtkomstkontroll genom loggning och logguppföljning samt patientens rätt att på begäran få veta vilken åtkomst som skett till uppgifter om hen. Gäller avvikelser som innehåller patientuppgifter även när de inte utgör journalhandlingar.
Konkretiserar patientdatalagen i praktiska åtgärder: dokumenterad behovs- och riskanalys som grund för behörighetstilldelning, systematisk och återkommande kontroll av åtkomstloggar samt stark autentisering och kryptering vid åtkomst över öppna nät. Sektion 15 samlar de krav som följer av PSL, HSL, PDL och dessa föreskrifter.
Kommunens information klassas utifrån konfidentialitet, riktighet och tillgänglighet. K3 är konfidentialitetsnivå 3 — information där ett röjande skulle ge allvarliga konsekvenser för verksamheten eller enskilda. Det är den klassningen som avgör att kraven på den här sidan gäller.
Frivillig standard med 93 säkerhetsåtgärder som stöd för ledningssystem enligt ISO 27001. Katalogen bygger på de bindande regelverken, men överlappar i praktiken standardens tekniska kontroller. Områden som personalsäkerhet, fysisk säkerhet och endpoint-skydd hanteras i kommunens centrala baseline snarare än per system.
Kraven täcker även in kommunens interna regler och riktlinjer som beskrivs i olika styrdokument — till exempel informationssäkerhetspolicy och instruktioner för informationsklassning och riskanalys. Katalogen är alltså en samlad, systemnära uttolkning av både externa och interna regelverk.
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| K3-01 | Informationsägare SKA vara identifierad för all K3-information. | Styrning · orgVerksamheten måste utse och dokumentera informationsägare för avvikelsedatat. | ✓ | |
| K3-02 | Informationsklassningen SKA vara genomförd innan utveckling eller anskaffning av ett system påbörjas. | Styrning · orgKlassningen måste vara beslutad innan utveckling startar — en grind i projektprocessen. | ✓ | |
| K3-03 | Systemägare och informationsägare SKA säkerställa att K3-kraven inkluderas i systemets arkitektur, utveckling och förvaltning. | Styrning · team+orgKravkatalogen måste följas upp löpande i arkitektur-, utvecklings- och förvaltningsbeslut. | ✗ | |
| K3-04 | Det SKA finnas en dokumenterad riskanalys för system som behandlar K3-information. | Styrning · orgRiskanalys måste genomföras, dokumenteras och hållas aktuell vid större förändringar. | ✗ | |
| K3-05 | Informationsflöden för K3-data SKA dokumenteras, inklusive lagring, integrationer, loggning, säkerhetskopiering och externa mottagare. | Rutin · teamTeamet måste ta fram och underhålla en flödeskarta över lagring, integrationer, loggning, backup och externa mottagare. | ||
| K3-06 | K3-information SKA separeras från information med lägre skyddsbehov när detta väsentligt minskar risken för obehörig åtkomst. | UtvecklingDatamodell och lagring måste utformas så att K3-data hålls åtskild från data med lägre klassning. | ✓ | |
| K3-07 | System innehållande K3-information SKA placeras i nätverkssegment med kontrollerade och dokumenterade informationsflöden. | InfrastrukturSystemet måste driftsättas i eget nätverkssegment med dokumenterade flöden. | ||
| K3-08 | Endast uttryckligen tillåtna nätverksflöden SKA tillåtas till och från K3-miljöer. | InfrastrukturBrandväggsregler enligt vitlista — all övrig trafik till och från miljön blockeras. |
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| K3-09 | All åtkomst till K3-information SKA ske med individuell digital identitet. | ApplikationInloggning måste ske via kommunens centrala identitetslösning (AD/OIDC) — inga lokala eller systemgemensamma konton. | ✓ | |
| K3-10 | Delade personliga användarkonton FÅR INTE användas. | Rutin · team+orgDelade konton får aldrig skapas eller lämnas ut — gäller både utvecklingsteamet och verksamhetens användare. | ✓ | |
| K3-11 | Behörighet SKA baseras på principerna least privilege och need-to-know. | UtvecklingRollbaserad behörighetsmodell med minsta möjliga rättigheter måste byggas in i lösningen. Styrning · orgRoller och tilldelning beslutas utifrån need-to-know. | ✓ | |
| K3-12 | En användare SKA endast få åtkomst till den K3-information och de funktioner som krävs för den aktuella arbetsuppgiften. | ApplikationBehörighetsstyrning på funktions- och informationsnivå — t.ex. att en enhetschef bara ser sin enhets avvikelser. | ✓ | |
| K3-13 | MFA SKA användas för mänsklig åtkomst till system som behandlar K3-information. | ApplikationInloggningen måste kräva MFA via den centrala identitetslösningen. | Oklart | Vad gäller för MFA och SSO? Undersök. |
| K3-14 | MFA SKA användas vid all privilegierad åtkomst och all extern fjärråtkomst. | InfrastrukturMFA måste aktiveras för admin- och fjärråtkomst — VPN, servrar, driftverktyg och molnkonsoler. | ||
| K3-15 | Phishing-resistent MFA, exempelvis FIDO2/WebAuthn eller motsvarande, BÖR användas för privilegierad åtkomst. | InfrastrukturFIDO2-/WebAuthn-nycklar bör införas för administratörer och privilegierade roller. | ||
| K3-16 | Administrativa konton SKA vara separerade från användarens ordinarie konto. | Rutin · team+orgAdmin-arbete måste ske från separata konton — aldrig från det ordinarie användarkontot. | ||
| K3-17 | Behörigheter SKA tas bort omedelbart när behovet upphör. | Rutin · team+orgOff-boarding- och behörighetsavslut måste ske direkt vid avslut eller ändrad roll, inte i efterhand. | ||
| K3-18 | Privilegierade behörigheter SKA granskas minst varje månad. Övriga K3-behörigheter SKA granskas minst kvartalsvis. | Rutin · team+orgÅterkommande behörighetsgranskning måste schemaläggas och dokumenteras — månadsvis för privilegierade konton, kvartalsvis för övriga. | ||
| K3-19 | Systemkonton och maskinidentiteter SKA ges minsta möjliga behörighet och får inte användas interaktivt av människor. | InfrastrukturTjänstekonton måste skapas per tjänst med minimala rättigheter och interaktiv inloggning spärrad. | ||
| K3-20 | Autentiseringsuppgifter från produktion FÅR INTE återanvändas i utveckling, test eller utbildning. | UtvecklingSeparata credentials per miljö — pipelines och konfiguration får aldrig återanvända produktionens. | ✓ |
Detta bör vara en av standardens viktigaste delar.
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| K3-21 | Utvecklare SKA normalt inte ha stående åtkomst till K3-produktionsdata. | Styrning · teamUtvecklares standardbehörighet får inte omfatta produktionsdata — påverkar hur teamet felsöker och supportar. | ||
| K3-22 | Rollen utvecklare SKA INTE i sig medföra rätt att läsa produktionsdata. | Styrning · teamBehörighetsmodellen för utvecklarrollen måste utformas utan läsrätt i produktion. | ||
| K3-23 | Systemadministrativ åtkomst SKA separeras från behörighet att läsa verksamhetsdata där tekniken medger detta. | ApplikationDrift-/adminroller måste konfigureras utan åtkomst till verksamhetsdata där tekniken tillåter. | ✗ | Lås ner API i WSO2 och kryptera nyckel, lås routing mot API:er, kryptera databas, payload loggas aldrig — kräver att vi kör frontend i OpenShift. |
| K3-24 | Direkt åtkomst till produktionsdatabas med K3-data FÅR INTE ges som normal utvecklarbehörighet. | InfrastrukturNätverksvägar från utvecklarklienter till produktionsdatabasen måste stängas; åtkomst endast via kontrollerad process. | ||
| K3-25 | Tillfällig produktionsåtkomst SKA ges genom en kontrollerad JIT-/PAM-/break-glass-process eller motsvarande. | InfrastrukturEn JIT-/PAM-lösning måste införas för tillfällig, tidsbegränsad åtkomst. Rutin · teamProcessen för att begära och bevilja åtkomst måste etableras. | ||
| K3-26 | Tillfällig åtkomst SKA vara kopplad till ett dokumenterat ärende eller incident, namngiven person och definierat ändamål. | Rutin · teamVarje åtkomstbegäran måste kopplas till ärende, namngiven person och ändamål. | ||
| K3-27 | Tillfällig åtkomst SKA godkännas av utsedd behörig roll och automatiskt upphöra efter fastställd tid. Normal maximal giltighetstid BÖR vara fyra timmar. | Rutin · team+orgGodkännandeflöde med utsedd godkännare och automatisk tidsgräns (normalt 4 h) måste konfigureras. | ||
| K3-28 | Tillfällig åtkomst SKA begränsas till minsta möjliga system, funktion och data. Read-only ska användas när skrivbehörighet inte uttryckligen behövs. | Rutin · teamÅtkomst beviljas smalast möjligt, med read-only som standardläge. | ||
| K3-29 | All användning av privilegierad K3-åtkomst SKA loggas på individnivå. | InfrastrukturPrivilegierad åtkomst måste loggas per person, t.ex. via PAM-/sessionsloggning. | ||
| K3-30 | Leverantörers privilegierade åtkomst SKA vara avstängd som normalläge och endast aktiveras för specifikt uppdrag. | Rutin · orgLeverantörskonton hålls inaktiverade och aktiveras endast per uppdrag, med avtalad process. | ||
| K3-31 | Privilegierad fjärradministration SKA ske från en förvaltad och säkerhetskontrollerad klient eller särskild administrativ miljö. | InfrastrukturAdministration endast från förvaltade klienter eller särskild administrativ miljö. | ||
| K3-32 | K3-information FÅR INTE kopieras till utvecklares lokala datorer, privata lagringsytor eller andra ej godkända miljöer. | Rutin · teamArbetssätt där K3-data aldrig lämnar godkända miljöer — kompletterat med tekniska spärrar (t.ex. DLP) där möjligt. |
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| K3-33 | Produktion SKA vara tekniskt separerad från utvecklings-, test- och utbildningsmiljö. | InfrastrukturSeparata miljöer för produktion, test och utveckling med teknisk isolering mellan dem. | Delvis | Test och produktion körs i dag delvis på samma server utan containrar — åtgärdas i och med flytten till OpenShift. |
| K3-34 | Produktionskonton, produktionscertifikat, produktionsnycklar och produktions-secrets FÅR INTE användas i utvecklings- eller testmiljö. | UtvecklingSeparata konton, certifikat, nycklar och secrets per miljö — hanterat i konfiguration och pipelines. | ✓ | |
| K3-35 | Produktionsdata klassad K3 FÅR INTE användas i utvecklings-, demo- eller utbildningsmiljö som normal metod. | Rutin · teamTest, demo och utbildning sker utan produktionsdata som normalläge. | ✓ | |
| K3-36 | Testdata SKA vara syntetisk, anonymiserad eller på annat sätt framställd så att den inte längre innehåller K3-information när detta är möjligt. | UtvecklingSyntetisk eller anonymiserad testdata måste tas fram och underhållas som del av utvecklingsarbetet. | ✓ | |
| K3-37 | Om verklig K3-data undantagsvis måste användas i test SKA miljön behandlas som K3-produktionsmiljö beträffande åtkomst, loggning och skydd. | InfrastrukturTestmiljön måste i undantagsfallet härdas till produktionsnivå — åtkomst, loggning och skydd. | ✓ | |
| K3-38 | Sådan användning SKA tidsbegränsas och godkännas av informationsägare och informationssäkerhetsfunktion. | Styrning · orgGodkännande av informationsägare och säkerhetsfunktion krävs, med tidsgräns. | ✓ | |
| K3-39 | K3-information SKA raderas från tillfälliga testmiljöer omedelbart efter avslutat ändamål, med beaktande av tillämpliga arkiv- och informationshanteringskrav. | Rutin · teamRaderingsrutin direkt efter avslutat ändamål, med hänsyn till arkivkrav. | ✓ |
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| K3-40 | K3-information SKA krypteras vid överföring över nätverk. | ApplikationAll kommunikation måste gå över TLS — även intern service-till-service-trafik. | ✗ | Saknas i kommunikationen till databas. |
| K3-41 | K3-information SKA som intern kommunal baslinje krypteras vid lagring, inklusive databaser, objektlagring, filsystem och säkerhetskopior. | ApplikationDatabas, objektlagring, filsystem och backuper måste krypteras vid lagring (at rest). | ✗ | Allt i detta krav saknas. |
| K3-42 | TLS 1.2 eller senare SKA användas. TLS 1.3 BÖR användas där det stöds. | InfrastrukturTLS-konfigurationen måste låsas till 1.2 eller senare, helst 1.3. | ✓ | |
| K3-43 | Äldre eller osäkra protokoll och kryptografiska algoritmer FÅR INTE användas. | InfrastrukturÄldre protokoll och svaga chiffer måste inaktiveras i all serverkonfiguration. | ✓ | |
| K3-44 | Kommunen SKA upprätthålla en separat aktuell kryptografisk profil som anger godkända algoritmer, protokoll och nyckellängder. | Styrning · orgKommunen måste ta fram och förvalta en kryptografisk profil som teamet sedan följer. | ||
| K3-45 | Krypteringsnycklar SKA lagras och hanteras separat från den information de skyddar. | InfrastrukturNyckelhantering i separat tjänst — inte i samma system eller databas som datat. | ||
| K3-46 | Nycklar och secrets SKA hanteras via godkänd KMS, HSM, secrets manager eller motsvarande central funktion. | UtvecklingApplikationen måste hämta nycklar och secrets från central KMS/secrets manager i stället för egen hantering. | ✗ | Saknas. |
| K3-47 | Krypteringsnycklar FÅR INTE lagras i källkod, container-images, konfigurationsfiler i klartext eller ärendehanteringssystem. | UtvecklingSecrets får aldrig checkas in — kräver secret scanning och säker konfigurationshantering. | ✓ | |
| K3-48 | Åtkomst till kryptografiska nycklar SKA vara separat behörighetsstyrd och loggad. | InfrastrukturNyckelvalvet måste ha egen behörighetsstyrning och åtkomstloggning. | ||
| K3-49 | Nycklar SKA kunna roteras och återkallas. | UtvecklingLösningen måste klara nyckelrotation utan driftstopp. Rutin · teamRotationsrutin med intervall och ansvar måste finnas. | Delvis | Huvudnyckelbyte till valvet kommer kräva driftstopp. Certifikat är dessutom inbyggda i container-images utan automatiserad rotation — centraliserad certifikathantering saknas och bör brytas ut som eget arbete. |
| K3-50 | Säkerhetsloggar och autentiseringsuppgifter SKA skyddas med kryptering vid överföring. | InfrastrukturLoggtransport (t.ex. till SIEM) och credential-flöden måste ske över krypterade kanaler. |
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| K3-51 | Autentisering och behörighetskontroll SKA genomföras server-side. Klientens uppgift om behörighet får aldrig ensam betraktas som betrodd. | UtvecklingAll autentisering och behörighetskontroll måste implementeras i backend — aldrig enbart i klienten. | ✓ | |
| K3-52 | API:er SKA kontrollera behörighet för varje relevant operation och resurs. | UtvecklingBehörighetskontroll på objekt- och operationsnivå (skydd mot BOLA/IDOR) måste byggas in i varje endpoint. | ✗ | Genomgången visade att Support Management-API:t saknar behörighetskontroll i backend — begränsningen ligger i frontend och kan kringgås. Måste åtgärdas server-side. |
| K3-53 | K3-information FÅR INTE exponeras genom publikt åtkomliga API:er utan autentisering. | ApplikationAPI:erna måste kräva autentisering och döljas/låsas i DevPortal så att inte vem som helst kan göra anrop mot produktion. | ✓ | |
| K3-54 | K3-information BÖR INTE placeras i URL:er eller query-parametrar eftersom dessa lätt hamnar i loggar, historik och mellanliggande system. | UtvecklingAPI-design utan känsliga uppgifter i URL:er eller query-parametrar — använd request body eller id:n. | ✓ | |
| K3-55 | Service-till-service-kommunikation med K3-information SKA använda stark autentisering, exempelvis OAuth2/OIDC-baserade maskinidentiteter, mTLS eller motsvarande. | UtvecklingOAuth2/OIDC-maskinidentiteter eller mTLS måste implementeras mellan tjänster. | ✓ | |
| K3-56 | Kortlivade tokens och credentials BÖR användas framför långlivade statiska nycklar. | UtvecklingTokenhantering med korta livslängder i stället för statiska API-nycklar. | ✓ | |
| K3-57 | Databasanvändare för applikationer SKA vara separerade från administrativa databaskonton. | ApplikationApplikationens databaskonto separeras från admin-konton och ges endast de rättigheter applikationen behöver. | ✓ | |
| K3-58 | Databaser SKA vara åtkomliga endast från godkända system och administrativa anslutningsvägar. | InfrastrukturDatabasens nätverksåtkomst begränsas till godkända system och kontrollerade admin-vägar. | ||
| K3-59 | Felmeddelanden från externa gränssnitt FÅR INTE exponera K3-information, secrets, stack traces eller intern systeminformation. | UtvecklingFelhanteringen måste byggas så att stack traces och intern information aldrig når externa gränssnitt. | ✓ | |
| K3-60 | Endast de K3-data som krävs för aktuell funktion SKA hämtas och exponeras. | UtvecklingAPI:er och vyer hämtar endast de fält som behövs — dataminimering i frågor och svar. | ✓ |
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| K3-61 | System som behandlar K3-information SKA utvecklas enligt etablerad metod för säker utveckling. | Styrning · teamTeamet måste anta och dokumenterat följa en metod för säker utveckling. | ✓ | |
| K3-62 | Kodändringar till produktionssystem SKA versionshanteras och vara spårbara till person och ändringsärende. | Rutin · teamAlla ändringar via versionshantering, kopplade till person och ändringsärende. | ✓ | |
| K3-63 | Kod till säkerhetskritiska delar SKA granskas av annan person innan produktionssättning. | Rutin · teamObligatorisk kodgranskning av annan person före produktionssättning. | ✓ | |
| K3-64 | Produktionsbranch SKA vara skyddad mot obehöriga direktändringar. | UtvecklingBranch protection måste konfigureras i repot — inga direktpushar till produktionsbranchen. | ✓ | |
| K3-65 | Secrets FÅR INTE lagras i Git-repository, pipelineskript eller motsvarande. | UtvecklingSecrets hanteras utanför repo och pipelineskript, med secret scanning som skyddsnät. | ✓ | |
| K3-66 | CI/CD-system SKA använda separata maskinidentiteter för produktion och andra miljöer. | UtvecklingPipelines måste konfigureras med separata maskinidentiteter per miljö. | ✓ | Kodpush och deploy sker med separata identiteter (GitHub respektive Argo CD/OpenShift); test och produktion deployas från samma repo där miljön skiljs via branch. |
| K3-67 | En utvecklare BÖR INTE genom sin vanliga utvecklaridentitet både kunna ändra programkod och självständigt kringgå produktionssättningens säkerhetskontroller. | UtvecklingRollseparation i CI/CD så att samma identitet inte både kan ändra kod och kringgå deployens kontroller. | ✓ | Uppfylls genom separata användarkonton — kodändring och deploy ligger splittat mellan olika system och identiteter. |
| K3-68 | SAST, dependency scanning och secret scanning SKA genomföras automatiskt i byggprocessen. | UtvecklingAutomatiska säkerhetsskanningar (SAST, dependency- och secret scanning) måste ingå i byggpipelinen. | Delvis | Dependency scanning (Dependabot) körs; secret scanning behöver aktiveras/bekräftas i GitHub. Frontend måste börja ta hand om resultaten från scanningar! |
| K3-69 | Säkerhetstester SKA genomföras före första produktionssättning och efter säkerhetsmässigt betydande förändringar. | Rutin · team+orgSäkerhetstest/penetrationstest måste planeras och beställas före första release och efter större förändringar. | ||
| K3-70 | Kända kritiska sårbarheter SKA åtgärdas eller riskaccepteras uttryckligen innan produktionssättning. | Rutin · teamRelease-grind: kritiska fynd åtgärdas eller riskaccepteras dokumenterat före produktionssättning. | ✓ | |
| K3-71 | Komponenter och beroenden SKA inventeras så att berörda system snabbt kan identifieras vid nyupptäckta sårbarheter. SBOM BÖR användas där det är praktiskt möjligt. | UtvecklingBeroendeinventering/SBOM måste genereras i bygget och hållas aktuell. | ✓ | Beroenden kan hämtas ut via GitHub och loggfiler ger snabb identifiering vid sårbarhetslarm; SBOM enligt standardformat paketeras inte i dag — läggs till senare med koppling till kommande SBOM-/systemregister. |
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| K3-72 | Åtkomst till K3-information SKA säkerhetsloggas. | UtvecklingÅtkomstloggning måste byggas in i applikationen — även läsningar av K3-data. | ✓ | Uppfylls via eventloggen; läsloggning stöds av datamodellen men behöver aktiveras i koden. |
| K3-73 | Loggen SKA, där det är relevant, kunna visa vem som fick åtkomst, vilken information eller resurs som berördes, vilken åtgärd som utfördes och när den utfördes. | UtvecklingLoggformatet måste innehålla identitet, resurs, åtgärd och tidpunkt. | ✓ | Identitet, resurs, åtgärd och tidpunkt loggas — "vi loggar allt". Notera spänningen mot maskningskravet K3-81. |
| K3-74 | Användning av administrativa rättigheter SKA loggas. | ApplikationAdministrativa åtgärder måste loggas i både applikation och underliggande plattform. | Oklart | Audit-logg i databasen misstänks saknas eller inte vara påslagen — måste kontrolleras. Binloggarna visar vad som hänt men inte vem. |
| K3-75 | Behörighetsförändringar SKA loggas. | ApplikationAlla tilldelningar och borttag av behörigheter måste loggas. | Delvis | Ändringar via AccessMapper/Support Management hamnar i eventloggen; AD-kopplingens loggning behöver undersökas. |
| K3-76 | Misslyckade och misstänkt obehöriga åtkomstförsök SKA loggas. | UtvecklingMisslyckade inloggningar och nekade åtkomstförsök måste loggas och kunna larmas på. | Delvis | Misslyckade försök (401:or) loggas, men larm saknas — tröskellarm i Grafana/ELK föreslås; ansvar IT-infra. |
| K3-77 | Säkerhetsloggar SKA skickas till ett centralt, åtkomstskyddat logg-/SIEM-system när detta är tekniskt möjligt. | InfrastrukturLoggarna måste skeppas till kommunens centrala SIEM-/loggsystem. | Delvis | Loggar skickas till central loggserver, men vid pod-krascher i OpenShift hinner loggar gå förlorade — standardiserad loggutskeppning pågår. |
| K3-78 | Den som administrerar ett K3-system BÖR INTE ensam kunna förändra eller radera säkerhetsloggen över sina egna aktiviteter. | InfrastrukturLoggar skrivs till ett system där systemets egna administratörer saknar ändringsrätt (append-only/central logg). | ||
| K3-79 | Loggar SKA analyseras med ett intervall baserat på risk. Relevant misstänkt aktivitet ska generera larm. | Rutin · orgRegelbunden logganalys och larmregler måste etableras hos SOC/driftfunktion. | ✗ | Larmkedja saknas och befintliga larm hanteras inte av någon mottagare — måste etableras tillsammans med IT-infra/SOC. |
| K3-80 | Säkerhetsloggar SKA ha en dokumenterad lagringstid som är tillräcklig för incidentutredning och rättsliga krav. | Styrning · orgRetentiontid för säkerhetsloggar måste beslutas och dokumenteras, avvägd mot GDPR. | ||
| K3-81 | Applikationsloggar FÅR INTE innehålla lösenord, autentiseringstokens, kryptografiska nycklar eller mer K3-information än vad som är nödvändigt. | UtvecklingLoggmaskning måste implementeras — inga lösenord, tokens eller onödig K3-data i apploggarna. | Delvis | Nyckelnamnsbaserad maskning finns (password, key, bearer m.m.) men K3-data i fritextfält maskas inte — överväg whitelist av payloadfält. Bedöms möjlig att åtgärda. |
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| K3-82 | Säkerhetskopior innehållande K3-information SKA ha minst samma konfidentialitetsskydd som originalinformationen. | InfrastrukturBackupmiljön måste ha samma åtkomstskydd och kryptering som produktionsmiljön. | ||
| K3-83 | K3-backup SKA krypteras. | InfrastrukturBackuplösningen måste konfigureras med kryptering av alla kopior. | ||
| K3-84 | Minst en återställningsbar kopia SKA vara logiskt eller fysiskt separerad så att kompromettering av produktionsmiljön inte automatiskt komprometterar samtliga kopior. | InfrastrukturMinst en kopia offline eller i separat miljö — skydd mot ransomware som når produktionen. | ||
| K3-85 | Återställning SKA testas regelbundet. | Rutin · team+orgRegelbundna, dokumenterade återställningstester tillsammans med driftfunktionen. | ||
| K3-86 | RTO (Recovery Time Objective — hur snabbt systemet ska vara återställt) och RPO (Recovery Point Objective — hur mycket data som får gå förlorad) SKA fastställas utifrån informations- och verksamhetsklassning. | Styrning · orgRTO och RPO måste beslutas tillsammans med verksamheten utifrån klassningen. | ||
| K3-87 | Åtkomst till backup SKA vara särskilt behörighetsstyrd och loggad. | InfrastrukturBackupsystemet måste ha egen behörighetsstyrning och åtkomstloggning. |
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| K3-88 | Informationsklassning och riskanalys SKA genomföras innan K3-information läggs hos extern leverantör. | Styrning · orgKlassning och riskanalys som obligatorisk grind före upphandling eller avrop. | N/A | |
| K3-89 | Leverantören SKA kontraktuellt omfattas av minst de säkerhetskrav som är relevanta för den del leverantören utför. | AvtalRelevanta säkerhetskrav måste skrivas in i leverantörsavtalet. | N/A | |
| K3-90 | Kommunen SKA känna till vilka underleverantörer som kan behandla eller få åtkomst till K3-information. | AvtalAvtalet måste kräva redovisning och godkännande av underleverantörer. | N/A | |
| K3-91 | Geografisk plats och jurisdiktion för behandling, lagring, backup och supportåtkomst SKA vara kända och riskbedömda. | Styrning · orgDataplacering och jurisdiktion måste kartläggas och riskbedömas före avtal. | N/A | |
| K3-92 | Leverantörens personal SKA INTE ha generell permanent åtkomst till K3-information. | AvtalAvtal och teknisk konfiguration måste stänga stående leverantörsåtkomst som normalläge. | N/A | |
| K3-93 | Supportåtkomst SKA vara personlig, MFA-skyddad, tidsbegränsad och loggad. | AvtalVillkoren för supportåtkomst regleras i avtal. InfrastrukturPersonliga MFA-konton med tidsgräns och loggning måste konfigureras. | N/A | |
| K3-94 | Avtalet SKA innehålla krav på incidentrapportering till kommunen. | AvtalIncidentrapporteringsskyldighet med tidsfrister måste skrivas in i avtalet. | N/A | |
| K3-95 | Avtalet SKA ge kommunen möjlighet att följa upp leverantörens efterlevnad av säkerhetskraven. | AvtalUppföljnings-/revisionsrätt i avtalet. Rutin · orgUppföljningen måste också genomföras återkommande. | N/A | |
| K3-96 | Avtalet SKA reglera återlämning, migrering och säker radering av kommunens information när avtalet upphör. | AvtalExitvillkor om återlämning, migrering och säker radering måste regleras i avtalet. | N/A | |
| K3-97 | Leverantörsberoenden och exitmöjlighet SKA analyseras innan tjänsten tas i bruk. | Styrning · orgBeroende- och exitanalys måste genomföras innan tjänsten tas i bruk. | N/A | |
| K3-98 | Kommunen SKA kunna avveckla leverantörens konton och åtkomst utan leverantörens medverkan eller inom en dokumenterat accepterad tidsperiod. | InfrastrukturKommunen måste tekniskt kunna stänga leverantörens konton och åtkomst på egen hand. | N/A | |
| K3-99 | Personuppgiftsbiträdesavtal SKA finnas när leverantören behandlar personuppgifter som personuppgiftsbiträde. | AvtalPuB-avtal måste tecknas innan leverantören behandlar personuppgifter. | N/A | |
| K3-100 | För sekretessbelagda uppgifter SKA en separat OSL-bedömning göras innan extern åtkomst eller behandling tillåts. | Styrning · orgSeparat OSL-bedömning (10 kap. 2 a §) måste göras innan extern behandling tillåts. | N/A |
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| K3-101 | K3-information FÅR INTE skickas till en extern generativ AI-tjänst som inte uttryckligen godkänts för K3. | Styrning · orgGodkännandeprocess för AI-tjänster krävs — endast K3-godkända tjänster får användas. | N/A | |
| K3-102 | Ett vanligt konsumentkonto hos en AI-tjänst FÅR INTE användas för behandling av K3-information. | Rutin · team+orgEndast konton under kommunens enterprise-avtal får användas — aldrig privata eller konsumentkonton. | N/A | |
| K3-103 | Innan K3-information behandlas av en AI-tjänst SKA leverantör, datalagring, supportåtkomst, underleverantörer, dataplacering och avtalsvillkor riskbedömas. | Styrning · orgRiskbedömning av leverantör, lagring, support, underleverantörer och avtal krävs före användning. | N/A | |
| K3-104 | Kommunens K3-information FÅR INTE användas för leverantörens generella modellträning eller andra egna ändamål. | AvtalAvtalet måste uttryckligen utesluta modellträning och egna ändamål med kommunens data. | N/A | |
| K3-105 | Prompter, bifogade dokument, embeddings, vektordatabaser, konversationshistorik och genererade svar SKA betraktas som K3 om de innehåller eller kan återskapa K3-information. | UtvecklingAll AI-relaterad data — prompter, embeddings, historik, svar — måste designas in i lösningens K3-skydd. | N/A | |
| K3-106 | Samma krav på kryptering, åtkomstkontroll, loggning, retention och radering SKA tillämpas på AI-relaterad databehandling som på annan K3-behandling. | ApplikationKryptering, åtkomstkontroll, loggning och radering måste tillämpas även på AI-flöden. | N/A | |
| K3-107 | RAG-/vektordatabaser SKA implementera behörighetskontroll som förhindrar att användaren genom AI-gränssnittet får information som denne inte hade rätt att läsa i källsystemet. | UtvecklingBehörighetsfiltrering måste byggas in i RAG-sökningen så att svar aldrig innehåller data användaren saknar rätt till. | N/A |
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| K3-108 | Misstänkt obehörig åtkomst till K3-information SKA behandlas som en informationssäkerhetsincident. | Rutin · team+orgMisstänkt obehörig åtkomst måste klassas som incident och eskaleras enligt incidentprocessen. | ||
| K3-109 | Incidentfunktionen SKA omedelbart kunna spärra användare, tokens, certifikat och administrativa sessioner. | ApplikationFunktioner för att omedelbart spärra användare, tokens, certifikat och sessioner måste finnas. | Delvis | AD-konton kan låsas (omedelbarheten beror på rutin); tokens invalideras vid nyutfärdande men central svepning behöver bekräftas (WSO2); certifikat är inbyggda i container-images och kan bara bytas genom ombyggnad (~20 min) — teknisk skuld. |
| K3-110 | Relevant bevismaterial och säkerhetsloggar SKA säkras innan system återställs om detta kan göras utan att förvärra incidenten. | Rutin · orgForensisk rutin: loggar och bevis säkras före återställning. | ||
| K3-111 | Incidenten SKA bedömas mot rapporteringskraven i cybersäkerhetslagen, GDPR och eventuell sektorslagstiftning. | Styrning · orgIncidentprocessen måste innehålla bedömning mot 24-/72-timmarsfristerna i NIS2 och GDPR. | ||
| K3-112 | Kritiska säkerhetsuppdateringar SKA hanteras skyndsamt genom en dokumenterad sårbarhetsprocess. | Rutin · team+orgDokumenterad sårbarhets- och patchprocess med skyndsam hantering av kritiska uppdateringar. | ✗ | Automatiska sårbarhets-PR:ar (Dependabot) åtgärdas inte konsekvent — ca 12 000 öppna varningar i kommunens GitHub-organisation utan utpekat ansvar. |
| K3-113 | System vars mjukvara inte längre får säkerhetsuppdateringar SKA avvecklas, uppgraderas eller omfattas av dokumenterade kompenserande åtgärder och accepterad risk. | Styrning · orgLivscykelbevakning av mjukvara — avveckla, uppgradera eller dokumentera kompenserande åtgärder och riskaccept. | N/A |
Riktighet 3 innebär att felaktig eller manipulerad information kan ge allvarliga konsekvenser — fel slutsatser och fel åtgärder i vård och omsorg. Kraven nedan kompletterar konfidentialitetskraven med skydd för informationens korrekthet.
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| R3-01 | Alla ändringar av ärendedata SKA loggas med vem som ändrade, vad som ändrades och när. | UtvecklingEn audit trail för alla ärendeändringar (vem, vad, när) måste byggas in i datamodellen. | Delvis | Eventloggen ger vem/vad/när på händelsenivå; spårbarhet på fältnivå krockar med loggmaskningen — scheman behöver ses över, alternativt krypteras loggen i stället för att maskas. |
| R3-02 | Ändringshistoriken SKA vara skyddad mot redigering och radering, även för administratörer. | UtvecklingHistoriken måste lagras append-only och vara oåtkomlig för ändring — även för administratörer. | Delvis | Append-only via API:t, men tjänstens databasanvändare har fulla rättigheter (Flyway) — bör strypas så att schemaändringar kräver tillfälligt grant. |
| R3-03 | Fastställt innehåll — beslut, utredningar och avslutade faser — SKA låsas eller versioneras så att ändringar i efterhand alltid är spårbara. | UtvecklingLåsnings-/versioneringsfunktion för fastställt innehåll måste byggas in. | ✓ | Per design |
| R3-04 | Validering och rimlighetskontroller av indata SKA genomföras server-side. Klientens validering får aldrig ensam betraktas som betrodd. | UtvecklingAll validering och rimlighetskontroll måste implementeras i backend, inte bara i klienten. | ✓ | Server-side-validering med formatkontroller (regex) samt skydd mot SQL- och logg-injection. |
| R3-05 | Säkerhetskopior och bilagor SKA skyddas mot manipulation, till exempel genom checksummor eller motsvarande integritetskontroller. | UtvecklingIntegritetskontroller (checksummor eller motsvarande) för backup och bilagor måste implementeras. | Delvis | Bilagor har checksumma/hash; integritetskontroll av säkerhetskopiorna är en infrastrukturfråga — bekräfta med backupansvariga. |
| R3-06 | Informationens integritet SKA verifieras vid återställning från säkerhetskopia. | Rutin · team+orgÅterställningsrutinen måste inkludera integritetsverifiering av återläst data. | ||
| R3-07 | Organisations- och behörighetsdata som hämtas från externa källor SKA valideras vid inläsning. Fel SKA upptäckas och rapporteras. | UtvecklingIntegrationer måste validera inläst data och larma vid fel. | Oklart | Källsystemen ansvarar för innehållet; signerade anrop (t.ex. Bolagsverket) kan ursprungsvalideras men det är obekräftat om valideringen görs — undersök. |
| R3-08 | Dataöverföringar mellan system SKA skyddas mot förvanskning genom integritetsskyddade protokoll. | InfrastrukturIntegritetsskyddade protokoll (TLS/signering) för alla överföringar mellan system. | ||
| R3-09 | Aggregeringar och statistik som lämnas till verksamheten SKA kunna härledas till underliggande grunddata. | UtvecklingStatistikfunktioner måste byggas så att siffror kan spåras tillbaka till grunddata. | ✓ | Grunddata finns alltid kvar och allt är härledbart; principen måste följa med in i den kommande statistikfunktionen. |
Tillgänglighet 2 innebär att verksamheten tål viss nedtid — en avvikelse kan vänta några timmar utan allvarlig skada. Kraven nedan preciserar därför K3-86 och sätter en medveten, måttlig ambitionsnivå för driften.
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| T2-01 | RTO (Recovery Time Objective — hur snabbt systemet ska vara återställt) och RPO (Recovery Point Objective — hur mycket data som får gå förlorad) SKA fastställas utifrån T2. Som riktvärde BÖR återställning kunna ske inom en arbetsdag och dataförlust begränsas till senaste dygnets säkerhetskopia. | Styrning · orgRiktvärdena — återställning inom en arbetsdag, högst ett dygns dataförlust — fastställs tillsammans med verksamheten. | ||
| T2-02 | Grundläggande driftövervakning med larm vid driftstörning SKA finnas. | InfrastrukturÖvervakning med larm vid driftstörning måste sättas upp. | ||
| T2-03 | En dokumenterad återstartsrutin SKA finnas och vara testad. | Rutin · team+orgDokumenterad återstartsrutin som testas tillsammans med driftfunktionen. | ||
| T2-04 | Planerade underhållsfönster SKA kommuniceras till verksamheten i förväg. | Rutin · orgKommunikationsrutin till verksamheten inför planerat underhåll. | ||
| T2-05 | Driftstörningar som påverkar verksamheten SKA kommuniceras till berörda. | Rutin · orgRutin för störningsinformation till berörda i verksamheten. |
Ärenden i förvaltningarnas lösningar — till exempel avvikelser — kan innehålla patientuppgifter, såsom personnummer, men utgör inte journalhandlingar. Patientdatalagens regler om personuppgiftsbehandling, inre sekretess och åtkomstkontroll gäller ändå — det är journalföringsreglerna som inte är tillämpliga. Kraven nedan kompletterar katalogen med det som följer av patientsäkerhetslagen, hälso- och sjukvårdslagen, patientdatalagen och HSLF-FS 2016:40.
| Id | Krav | Påverkan | Uppfyllt | Kommentar |
|---|---|---|---|---|
| PD-01 | Behörighetstilldelning till avvikelser som innehåller patientuppgifter SKA baseras på en dokumenterad behovs- och riskanalys enligt HSLF-FS 2016:40. | Styrning · orgVårdgivaren måste dokumentera vilken åtkomst varje personalkategori behöver och lägga analysen till grund för behörighetsmodellen — går längre än principen i K3-11. | ||
| PD-02 | Åtkomst till patientkopplade avvikelser SKA kontrolleras systematiskt och återkommande genom logguppföljning, till exempel stickprovsvis granskning. | Rutin · orgVerksamheten måste etablera en återkommande loggranskningsrutin — en verksamhetskontroll av vem som faktiskt tittat, utöver den tekniska larmningen i K3-79. | ||
| PD-03 | Åtkomstloggen SKA kunna sammanställas per patient så att patienten på begäran kan få information om vilken åtkomst som förekommit till uppgifter om hen. | UtvecklingLoggutdrag per patient måste kunna tas fram i läsbar form — ställer krav på loggformatet i K3-73. Rutin · orgRutin för att hantera och besvara patientens begäran måste finnas. | Delvis | Indirekt möjligt: patientens ärenden kan tas fram och åtkomstloggen hämtas per ärende — kräver aktiverad läsloggning och en manuell rutin, inget knapptryck. |
| PD-04 | Incidenter och avvikelser SKA bedömas mot anmälningsskyldigheten enligt lex Maria (PSL 3 kap. 5 §) respektive lex Sarah (SoL 14 kap. 7 §), utöver rapporteringskraven i cybersäkerhetslagen och GDPR. | Styrning · orgIncidentprocessen i K3-111 måste kompletteras med IVO-spåret — en IT-incident som påverkar patientsäkerheten kan utlösa flera rapporteringsspår samtidigt. | ||
| PD-05 | Avvikelsedata SKA årligen kunna aggregeras och sammanställas som underlag till patientsäkerhetsberättelsen (PSL 3 kap. 10 §). | UtvecklingAggregerings- och exportfunktioner måste finnas så att årets avvikelser kan sammanställas — bygger på härledbarheten i R3-09. | ✗ | Aggregerings-/exportfunktion finns inte i dag — planeras lösas via statistikfunktionen. |
| PD-06 | Bevarande- och gallringstider för avvikelser med patientuppgifter SKA fastställas i kommunens dokumenthanteringsplan. Radering enligt K3-39 och K3-96 SKA ske med beaktande av dessa tider. | Styrning · orgAvvikelser är allmänna handlingar — gallring kräver stöd i dokumenthanteringsplanen och får inte ske genom generella raderingsrutiner. | ||
| PD-07 | Personnummer och andra direkta patientidentifierare SKA registreras i därför avsedda strukturerade fält, inte i fritext. | UtvecklingDatamodellen måste ha separata fält för identifierare så att behörighetsstyrning, maskning, loggutdrag och gallring fungerar per patient. Rutin · orgRapportörer måste instrueras att inte skriva personnummer i fritextfält. | ✓ | Datamodellen har separata fält för identifierare; fritextregistrering kan inte förhindras tekniskt utan hanteras via instruktion. Party-ID ger viss pseudonymisering. |