Vad H SystSäk 2022 kräver av en leverantör

H SystSäk 2022 — Försvarsmaktens handbok för systemsäkerhet, version 3.0, gällande sedan september 2022 — är öppet publicerad och fritt nedladdningsbar från FMV:s sidor om systemsäkerhet, tillsammans med leverantörsvägledning och dokumentmallar. Den organiserar arbetet kring fyra roller, varav tre möter en typisk leverantör: kravställaren (Försvarsmakten, som ställer kraven och till slut ger godkännandet), beställaren (FMV, som avtalar och styr arbetet) och konstruktören — leverantören, som realiserar det tekniska systemet och lämnar sitt eget formella utlåtande. (Den fjärde, systemintegratören, säkrar samspelet i system av system och sitter hos FMV eller Försvarsmakten.) Kraven flödar ned genom den kedjan, och leverantören får lägga till fler aktiviteter än beställaren begärt — att stryka en valbar aktivitet kräver däremot ett medvetet och dokumenterat beslut i planen.

Två saker om tidpunkter väger tyngre än något annat i handboken. För det första: leverantörens systemsäkerhetsarbete börjar så snart avtalet är påskrivet — aktiviteterna skrivs in i avtalet, de skruvas inte på i efterhand strax före leverans. För det andra: handboken noterar att en preliminär systemsäkerhetsplan kan användas före avtal, för att bedöma en tänkbar leverantörs förståelse för och prioritering av systemsäkerhet. Er kompetens på området bedöms alltså redan medan ni lämnar anbud.

Leverantörens centrala dokument är systemsäkerhetsplanen, SSPP (TASK 102) — en del av avtalet, med innehåll och omfattning styrda av det. Den beskriver systemet och organisationen, tillämplig EU-rätt och svensk lagstiftning jämte standarder och hur kravanalysen ska genomföras, den tolerabla risknivån uttryckt i riskmatriser, de valda vägarna genom bedömningsmodellen, vilka analyser som ska utföras, hur verifiering och validering går till, hur risker avslutas och begränsningar hanteras, hur de avslutande dokumenten tas fram — och vilka systemsäkerhetskrav leverantören ställer på sina egna underleverantörer. Leverantören får lägga till aktiviteter utöver vad beställaren krävt; den får inte tyst utelämna dem.

Bakom planen ligger en aktivitetskatalog i fem avsnitt — planering och ledning, analyser, värdering, verifiering och beslut — till stor del byggd på aktivitetsstrukturen i MIL-STD-882E, med ett svenskt femte avsnitt för de formella säkerhetsbesluten. Varje avsnitt har obligatoriska aktiviteter och en valbar nivå, och valbara aktiviteter kan ibland ersättas av aktiviteter ur andra standarder eller av leverantörens egna motsvarigheter — förutsatt att varje val, och varje förenkling mot aktivitetsbeskrivningarna, dokumenteras i planen. Att arbeta enligt en annan etablerad systemsäkerhetsstandard är möjligt på samma villkor — handboken noterar att arbetet då kan behöva kompletteras med de unika svenska aktiviteterna och med en korsreferenslista mellan standarderna. Anpassning är tillåten; odokumenterad anpassning är det inte.

Analyserna börjar i riskerna. Den funktionella riskanalysen (FHA) identifierar de säkerhetskritiska funktionerna — inklusive dem som realiseras i mjukvara, vilka går vidare till kriticitetsnivåer som hanteras enligt H ProgSäk, FMV:s systerhandbok från 2018 för mjukvara i säkerhetskritiska tillämpningar. Dess eget förord slår fast principen rakt ut: handboken har ingen egen rättslig status; dess krav blir bindande först när den upphandlande sidan skriver in dem i avtalet. Tillsammans med risklistan (PHL) och riskanalysen (PHA) matar FHA sedan systemsäkerhetskravanalysen (SRHA, TASK 203), där leverantören omsätter EU-rätt, svensk lagstiftning, standarder, avtalet och sina egna interna krav — plus motåtgärderna mot de identifierade riskerna — till systemsäkerhetskrav, vart och ett verifierbart, eftersom det plockas upp igen i verifieringsaktiviteten på slutet.

Därifrån går kedjan ned till de nivåer en leverantör faktiskt konstruerar på: delsystem, system och hantering — användning, underhåll, förvaring och transport. Och handboken är precis med vad som hamnar i riskmatrisen: bara de risker som inte kunnat avslutas genom bedömningsmodellens övriga vägar värderas mot den tolerabla risknivån — fyra konsekvensklasser (I–IV) korsade med sex sannolikhetsklasser (A–F, där F är reserverad för risker som konstruerats bort helt), med gränsen mellan rött och gult som definierar den risknivå Försvarsmakten kan acceptera. Försvarsmaktens generella matriser gäller om inte särskilda skäl finns; en matris anpassad för ett produktområde eller ett specifikt system definieras i Försvarsmaktens egen ledningsplan (SSMP) och når leverantören genom kravdokumenten — planen återger sedan den tolerabla risknivån uttryckt i de matriserna.

Handbokens bedömningsmodell — vägvalsmodellen — är hur en leverantör argumenterar för att systemet är tillräckligt säkert. Sju vägar: författningskrav, godkännande av annan stat, godkännande av annan part, andra etablerade standarder, konstruktionsregler, beprövade system, och slutligen riskmatriserna för det som återstår. Leverantören föreslår vägarna i sin plan; ändringar kommer man överens om med beställaren inom avtalet och dokumenterar. En väg är uttryckligen stängd för industrin: en leverantör kan inte åberopa en annan stats godkännande i sin egen bedömning.

För en leverantör med fordonsbakgrund är det fjärde vägvalet där de befintliga bevisen kommer in: arbete enligt etablerade standarder räknas, förutsatt att motiven för de valda standarderna anges, att de tillämpade kraven — inklusive vald kriticitetsnivå — redovisas, och att det finns verifieringskriterier med resultat som visar att kraven är uppfyllda. Det är precis här bevis enligt ISO 26262 och IEC 61508 möter handboken, tillsammans med den korsreferenslista vi beskrev i jämförelsen mellan ISO 26262 och MIL-STD-882E. Handboken granskar också kvaliteten på själva argumentet: påståenden om att användaren inte kan antas begå vissa fel pekas ut som felaktiga argument som inte får förekomma, och en oberoende tredje parts certifiering mot en standard väger tyngre som bevis än egen verifiering mot samma standard.

Bevisryggraden är riskhanteringssystemet (HTS, TASK 106) och dess risklogg — och den är en stafettpinne, inte en rapport. Kravställaren startar loggen med de vanligt förekommande riskerna, beställaren får komplettera, leverantören lägger till varje risk som identifieras under utvecklingen, och vid leverans tar beställaren över loggen för fortsatt förvaltning — innan den lämnas vidare till kravställaren för det avslutande skedet, så att loggen förvaltas hos alla tre aktörerna under systemets hela liv. Varje post bär bedömningen före och efter åtgärd, verifieringsmetoden, acceptansbesluten och aktuell status. En logg som den, förvaltad i decennier tvärs över organisationer, är lika mycket ett konfigurationsledningsproblem som ett säkerhetsproblem — samma dokumentationsdisciplin som våra diagnostikplattformar är byggda på.

De avslutande dokumenten följer ur dokumentationen. Systemsäkerhetsrapporten (SAR, TASK 301) sammanfattar arbetet: efterlevnaden mot lagstiftning och avtal, varje risk beskriven, de valda vägarna och motiven för dem. Verifieringen (TASK 401) visar att kraven är uppfyllda och att systemet svarar mot behovet — och matar leverantörens beslutsdokument: systemsäkerhetsutlåtandet (SCA), leverantörens formella ställningstagande före leverans om att den lagstiftning som gäller vid leverans och kundens systemsäkerhetskrav är uppfyllda, byggt på argumenten och bevisen från de tillämpade vägvalen. Notera gränsen: leverantören uttalar sig; den godkänner aldrig. Deklarationen ovanpå — systemsäkerhetsdeklarationen (SSD) — är beställarens, och godkännandet — systemsäkerhetsgodkännandet (SSG) — tillsammans med besluten om användning på central och lokal nivå tillhör Försvarsmakten.

Det mesta av vad H SystSäk 2022 begär är arbetssätt en fordonsleverantör redan har: kravdriven analys, krav på noggrannhet graderade efter allvarlighet, verifiering med bevis, konfigurationsstyrning och en spårbar dokumentation från risk till avslut. Det som måste läras in är ramen runt omkring — aktivitetsnamnen och deras leveranser, rollgränserna, vägvalsargumentationen och den svenska beslutskedjan från utlåtande till godkännande. Handboken sänker själv tröskeln: den är offentlig, systerhandboken H ProgSäk är offentlig, MIL-STD-882E är offentlig, och FMV publicerar leverantörsvägledning och mallar för systemsäkerhetsplanen, rapporten och riskloggen öppet. Tröskeln är inte tillgången — det är översättningen.

Den översättningen är den resa vi själva är på: vi lär oss kontinuerligt av handboken och formar vår leveransmodell kring dess aktiviteter — hur vi arbetar med standarder beskriver var vi står, och försvarsöversikten visar de program disciplinen kommer ur. För en leverantör som väger steget in i svensk försvarsupphandling är det ärliga rådet handbokens eget: börja systemsäkerhetsarbetet med anbudet, inte efter avtalet — för när en preliminär systemsäkerhetsplan väl ligger på bordet har bedömningen av er disciplin redan börjat.