Säkerhetskrav K3 R3 T2 · Avvikelsehantering

sektion 00

Regelverken bakom kraven

Kraven i katalogen hänvisar till ett antal lagar, föreskrifter och modeller. Här är en kort orientering om vad de är.

Cybersäkerhetslagen

Svensk lag som genomför EU:s NIS2-direktiv

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.

MCFFS

Myndigheten för civilt försvars författningssamling

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.

GDPR

EU:s dataskyddsförordning

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).

OSL

Offentlighets- och sekretesslagen (2009:400)

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.

K3 · KLASSA

Informationsklassning enligt SKR:s modell

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.

ISO/IEC 27002

Internationell standard för säkerhetsåtgärder

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.

Kommunens styrdokument

Interna regler och riktlinjer

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.

Avgränsning: katalogen gäller klassningen K3 R3 T2. Säkerhetsskyddsklassificerade uppgifter (skyddsnivå 4 — uppgifter av betydelse för Sveriges säkerhet) omfattas av ett separat regelverk enligt säkerhetsskyddslagen och får inte hanteras i systemet.

sektion 01

1. Informationsklassning och grundläggande arkitektur

Id	Krav	Uppfyllt
K3-01	Informationsägare SKA vara identifierad för all K3-information.	✓
K3-02	Informationsklassningen SKA vara genomförd innan utveckling eller anskaffning av ett system påbörjas.	✓
K3-03	Systemägare och informationsägare SKA säkerställa att K3-kraven inkluderas i systemets arkitektur, utveckling och förvaltning.	✓
K3-04	Det SKA finnas en dokumenterad riskanalys för system som behandlar K3-information.	✓
K3-05	Informationsflöden för K3-data SKA dokumenteras, inklusive lagring, integrationer, loggning, säkerhetskopiering 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.	✓
K3-07	System innehållande K3-information SKA placeras i nätverkssegment med kontrollerade och dokumenterade informationsflöden.
K3-08	Endast uttryckligen tillåtna nätverksflöden SKA tillåtas till och från K3-miljöer.

MCFFS kräver informationsklassning, riskbaserat arbete och segmentering med endast godkända informationsflöden.

sektion 02

2. Identitet och behörighet

Id	Krav	Uppfyllt
K3-09	All åtkomst till K3-information SKA ske med individuell digital identitet.	✓
K3-10	Delade personliga användarkonton FÅR INTE användas.	✓
K3-11	Behörighet SKA baseras på principerna least privilege och 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.	✓
K3-13	MFA SKA användas för mänsklig åtkomst till system som behandlar K3-information.
K3-14	MFA SKA användas vid all privilegierad åtkomst och all extern fjärråtkomst.
K3-15	Phishing-resistent MFA, exempelvis FIDO2/WebAuthn eller motsvarande, BÖR användas för privilegierad åtkomst.
K3-16	Administrativa konton SKA vara separerade från användarens ordinarie konto.
K3-17	Behörigheter SKA tas bort omedelbart när behovet upphör.
K3-18	Privilegierade behörigheter SKA granskas minst varje månad. Övriga K3-behörigheter SKA granskas minst kvartalsvis.
K3-19	Systemkonton och maskinidentiteter SKA ges minsta möjliga behörighet och får inte användas interaktivt av människor.
K3-20	Autentiseringsuppgifter från produktion FÅR INTE återanvändas i utveckling, test eller utbildning.

MCFFS 4 kap. 16–17 §§ kräver bland annat minsta nödvändiga behörighet, restriktiv systemadministrativ behörighet, separata produktionscredentials och MFA för system som behandlar information i behov av utökat skydd.

sektion 03

3. Utvecklares och administratörers åtkomst till produktion

Detta bör vara en av standardens viktigaste delar.

Id	Krav	Uppfyllt
K3-21	Utvecklare SKA normalt inte ha stående åtkomst till K3-produktionsdata.
K3-22	Rollen utvecklare SKA INTE i sig medföra rätt att läsa produktionsdata.
K3-23	Systemadministrativ åtkomst SKA separeras från behörighet att läsa verksamhetsdata där tekniken medger detta.
K3-24	Direkt åtkomst till produktionsdatabas med K3-data FÅR INTE ges som normal utvecklarbehörighet.
K3-25	Tillfällig produktionsåtkomst SKA ges genom en kontrollerad JIT-/PAM-/break-glass-process eller motsvarande.
K3-26	Tillfällig åtkomst SKA vara kopplad till ett dokumenterat ärende eller incident, namngiven person och definierat ä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.
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.
K3-29	All användning av privilegierad K3-åtkomst SKA loggas på individnivå.
K3-30	Leverantörers privilegierade åtkomst SKA vara avstängd som normalläge och endast aktiveras för specifikt uppdrag.
K3-31	Privilegierad fjärradministration SKA ske från en förvaltad och säkerhetskontrollerad klient 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.

Detta går längre än ordalydelsen i lagen på vissa punkter, men operationaliserar kraven på restriktiv administrativ behörighet, tidsbegränsning och spårbarhet. MCFFS anger uttryckligen att systemadministrativ behörighet ska tilldelas restriktivt och att leverantörers administrativa behörighet bör begränsas i både omfattning och tid.

sektion 04

4. Separation mellan produktion, test och utveckling

Id	Krav	Uppfyllt
K3-33	Produktion SKA vara tekniskt separerad från utvecklings-, test- och utbildningsmiljö.	✓
K3-34	Produktionskonton, produktionscertifikat, produktionsnycklar och produktions-secrets FÅR INTE användas i utvecklings- eller testmiljö.	✓
K3-35	Produktionsdata klassad K3 FÅR INTE användas i utvecklings-, demo- eller utbildningsmiljö som normal metod.	✓
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.	✓
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.	✓
K3-38	Sådan användning SKA tidsbegränsas och godkännas av informationsägare och informationssäkerhetsfunktion.	✓
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.	✓

Separationen mellan produktions- och utvecklings-/testmiljö anges uttryckligen i MCFFS 4 kap. 12 §.

sektion 05

5. Kryptering

Id	Krav	Uppfyllt
K3-40	K3-information SKA krypteras vid överföring över nätverk.	✓
K3-41	K3-information SKA som intern kommunal baslinje krypteras vid lagring, inklusive databaser, objektlagring, filsystem och säkerhetskopior.
K3-42	TLS 1.2 eller senare SKA användas. TLS 1.3 BÖR användas där det stöds.	✓
K3-43	Äldre eller osäkra protokoll och kryptografiska algoritmer FÅR INTE användas.	✓
K3-44	Kommunen SKA upprätthålla en separat aktuell kryptografisk profil som anger godkända algoritmer, protokoll och nyckellängder.
K3-45	Krypteringsnycklar SKA lagras och hanteras separat från den information de skyddar.
K3-46	Nycklar och secrets SKA hanteras via godkänd KMS, HSM, secrets manager eller motsvarande central funktion.	✓
K3-47	Krypteringsnycklar FÅR INTE lagras i källkod, container-images, konfigurationsfiler i klartext eller ärendehanteringssystem.
K3-48	Åtkomst till kryptografiska nycklar SKA vara separat behörighetsstyrd och loggad.
K3-49	Nycklar SKA kunna roteras och återkallas.
K3-50	Säkerhetsloggar och autentiseringsuppgifter SKA skyddas med kryptering vid överföring.

MCFFS 4 kap. 25 § kräver en riskbaserad hantering av krypteringsbehovet och kräver kryptering av bland annat information i behov av utökat skydd när den överförs till system utanför den digitala miljön. Det allmänna rådet anger också kryptering vid lagring för information i behov av utökat skydd och kontrollerad nyckelhantering. GDPR artikel 32 pekar dessutom uttryckligen ut pseudonymisering och kryptering som möjliga riskanpassade säkerhetsåtgärder för personuppgifter.

sektion 06

6. Applikationer, API:er och databaser

Id	Krav	Uppfyllt
K3-51	Autentisering och behörighetskontroll SKA genomföras server-side. Klientens uppgift om behörighet får aldrig ensam betraktas som betrodd.	✓
K3-52	API:er SKA kontrollera behörighet för varje relevant operation och resurs.
K3-53	K3-information FÅR INTE exponeras genom publikt åtkomliga API:er utan autentisering.	✓
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.
K3-55	Service-till-service-kommunikation med K3-information SKA använda stark autentisering, exempelvis OAuth2/OIDC-baserade maskinidentiteter, mTLS eller motsvarande.	✓
K3-56	Kortlivade tokens och credentials BÖR användas framför långlivade statiska nycklar.	✓
K3-57	Databasanvändare för applikationer SKA vara separerade från administrativa databaskonton.
K3-58	Databaser SKA vara åtkomliga endast från godkända system och administrativa anslutningsvägar.
K3-59	Felmeddelanden från externa gränssnitt FÅR INTE exponera K3-information, secrets, stack traces eller intern systeminformation.
K3-60	Endast de K3-data som krävs för aktuell funktion SKA hämtas och exponeras.

sektion 07

7. Säker utvecklingsprocess och CI/CD

Id	Krav	Uppfyllt
K3-61	System som behandlar K3-information SKA utvecklas enligt etablerad metod för säker utveckling.	✓
K3-62	Kodändringar till produktionssystem SKA versionshanteras och vara spårbara till person och ändringsärende.	✓
K3-63	Kod till säkerhetskritiska delar SKA granskas av annan person innan produktionssättning.	✓
K3-64	Produktionsbranch SKA vara skyddad mot obehöriga direktändringar.	✓
K3-65	Secrets FÅR INTE lagras i Git-repository, pipelineskript eller motsvarande.	✓
K3-66	CI/CD-system SKA använda separata maskinidentiteter för produktion och andra miljöer.
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.
K3-68	SAST, dependency scanning och secret scanning SKA genomföras automatiskt i byggprocessen.	✓
K3-69	Säkerhetstester SKA genomföras före första produktionssättning och efter säkerhetsmässigt betydande förändringar.
K3-70	Kända kritiska sårbarheter SKA åtgärdas eller riskaccepteras uttryckligen innan 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.

Cybersäkerhetslagen omfattar uttryckligen säkerhet vid förvärv, utveckling och underhåll, och MCFFS kräver bland annat informationsklassning, riskanalys och etablerade metoder för säker utveckling samt säkerhetstester och granskningar.

sektion 08

8. Loggning och spårbarhet

Id	Krav	Uppfyllt
K3-72	Åtkomst till K3-information SKA säkerhetsloggas.
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.
K3-74	Användning av administrativa rättigheter SKA loggas.
K3-75	Behörighetsförändringar SKA loggas.
K3-76	Misslyckade och misstänkt obehöriga åtkomstförsök SKA loggas.
K3-77	Säkerhetsloggar SKA skickas till ett centralt, åtkomstskyddat logg-/SIEM-system när detta är tekniskt möjligt.
K3-78	Den som administrerar ett K3-system BÖR INTE ensam kunna förändra eller radera säkerhetsloggen över sina egna aktiviteter.
K3-79	Loggar SKA analyseras med ett intervall baserat på risk. Relevant misstänkt aktivitet ska generera larm.
K3-80	Säkerhetsloggar SKA ha en dokumenterad lagringstid som är tillräcklig för incidentutredning och rättsliga krav.
K3-81	Applikationsloggar FÅR INTE innehålla lösenord, autentiseringstokens, kryptografiska nycklar eller mer K3-information än vad som är nödvändigt.

MCFFS 4 kap. 21 § anger uttryckligen säkerhetsloggning av bland annat systemåtkomst, systemadministrativa rättigheter, behörighetsförändringar och åtkomst till information i behov av utökat skydd. Loggarna ska dessutom skyddas och analyseras.

sektion 09

9. Backup, kontinuitet och återställning

Id	Krav	Uppfyllt
K3-82	Säkerhetskopior innehållande K3-information SKA ha minst samma konfidentialitetsskydd som originalinformationen.
K3-83	K3-backup SKA krypteras.
K3-84	Minst en återställningsbar kopia SKA vara logiskt eller fysiskt separerad så att kompromettering av produktionsmiljön inte automatiskt komprometterar samtliga kopior.
K3-85	Återställning SKA testas regelbundet.
K3-86	RTO och RPO SKA fastställas utifrån informations- och verksamhetsklassning.
K3-87	Åtkomst till backup SKA vara särskilt behörighetsstyrd och loggad.

MCFFS kräver att information ska kunna återställas inom fastställda tider och anger som allmänt råd bland annat att minst en säkerhetskopia bör skyddas genom separation från källsystemet.

sektion 10

10. Leverantörer, SaaS och molntjänster

Id	Krav	Uppfyllt
K3-88	Informationsklassning och riskanalys SKA genomföras innan K3-information läggs hos extern leverantör.	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.	N/A
K3-90	Kommunen SKA känna till vilka underleverantörer som kan behandla eller få åtkomst till K3-information.	N/A
K3-91	Geografisk plats och jurisdiktion för behandling, lagring, backup och supportåtkomst SKA vara kända och riskbedömda.	N/A
K3-92	Leverantörens personal SKA INTE ha generell permanent åtkomst till K3-information.	N/A
K3-93	Supportåtkomst SKA vara personlig, MFA-skyddad, tidsbegränsad och loggad.	N/A
K3-94	Avtalet SKA innehålla krav på incidentrapportering till kommunen.	N/A
K3-95	Avtalet SKA ge kommunen möjlighet att följa upp leverantörens efterlevnad av säkerhetskraven.	N/A
K3-96	Avtalet SKA reglera återlämning, migrering och säker radering av kommunens information när avtalet upphör.	N/A
K3-97	Leverantörsberoenden och exitmöjlighet SKA analyseras 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.	N/A
K3-99	Personuppgiftsbiträdesavtal SKA finnas när leverantören behandlar personuppgifter som personuppgiftsbiträde.	N/A
K3-100	För sekretessbelagda uppgifter SKA en separat OSL-bedömning göras innan extern åtkomst eller behandling tillåts.	N/A

MCFFS ställer uttryckliga krav på riskbedömning före utkontraktering, att leverantören kan uppfylla relevanta säkerhetskrav under avtalstiden samt att avtalen möjliggör att säkerhetsåtgärder upprätthålls över tid. De allmänna råden tar bland annat upp underleverantörer, incidenter, uppföljning och återlämning eller förstöring av information.

För sekretessbelagda kommunala uppgifter är OSL-bedömningen separat från GDPR och informationssäkerhetsbedömningen. 10 kap. 2 a § OSL medger under vissa förutsättningar utlämnande till en aktör som endast tekniskt bearbetar eller lagrar uppgiften, om utlämnandet inte är olämpligt.

sektion 11

11. K3 och AI-tjänster

Id	Krav	Uppfyllt
K3-101	K3-information FÅR INTE skickas till en extern generativ AI-tjänst som inte uttryckligen godkänts för K3.	N/A
K3-102	Ett vanligt konsumentkonto hos en AI-tjänst FÅR INTE användas för behandling av K3-information.	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.	N/A
K3-104	Kommunens K3-information FÅR INTE användas för leverantörens generella modellträning eller andra egna ändamål.	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.	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.	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.	N/A

Det sista kravet är särskilt viktigt: AI får inte bli en bakdörr runt ordinarie informationsbehörighet.

sektion 12

12. Incidenter och sårbarheter

Id	Krav	Uppfyllt
K3-108	Misstänkt obehörig åtkomst till K3-information SKA behandlas som en informationssäkerhetsincident.
K3-109	Incidentfunktionen SKA omedelbart kunna spärra användare, tokens, certifikat och administrativa sessioner.
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.
K3-111	Incidenten SKA bedömas mot rapporteringskraven i cybersäkerhetslagen, GDPR och eventuell sektorslagstiftning.
K3-112	Kritiska säkerhetsuppdateringar SKA hanteras skyndsamt genom en dokumenterad sårbarhetsprocess.
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.	N/A

Cybersäkerhetslagen kräver tidig information om betydande incidenter senast inom 24 timmar och en incidentanmälan normalt senast inom 72 timmar. Personuppgiftsincidenter omfattas samtidigt av GDPR:s separata 72-timmarsregel när förutsättningarna för anmälningsskyldighet är uppfyllda.

sektion 13

13. Riktighet och spårbarhet (R3)

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	Uppfyllt
R3-01	Alla ändringar av ärendedata SKA loggas med vem som ändrade, vad som ändrades och när.
R3-02	Ändringshistoriken SKA vara skyddad mot redigering och radering, även för administratörer.
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.
R3-04	Validering och rimlighetskontroller av indata SKA genomföras server-side. Klientens validering får aldrig ensam betraktas som betrodd.
R3-05	Säkerhetskopior och bilagor SKA skyddas mot manipulation, till exempel genom checksummor eller motsvarande integritetskontroller.
R3-06	Informationens integritet SKA verifieras vid återställning från säkerhetskopia.
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.
R3-08	Dataöverföringar mellan system SKA skyddas mot förvanskning genom integritetsskyddade protokoll.
R3-09	Aggregeringar och statistik som lämnas till verksamheten SKA kunna härledas till underliggande grunddata.

Riktighetskraven följer av R3 i klassningen. MCFFS och GDPR artikel 32 omfattar uttryckligen skydd av informationens riktighet, inte bara dess konfidentialitet.

sektion 14

14. Tillgänglighet (T2)

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	Uppfyllt
T2-01	RTO och RPO 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.
T2-02	Grundläggande driftövervakning med larm vid driftstörning SKA finnas.
T2-03	En dokumenterad återstartsrutin SKA finnas och vara testad.
T2-04	Planerade underhållsfönster SKA kommuniceras till verksamheten i förväg.
T2-05	Driftstörningar som påverkar verksamheten SKA kommuniceras till berörda.

T2 begränsar snarare än utökar: högtillgänglighetslösningar som klustring eller redundans över flera siter krävs inte — grundläggande övervakning, larm och en testad återstartsrutin är tillräckligt. Riktvärdena i T2-01 fastställs slutligt tillsammans med verksamheten.