CRA teknisk dokumentation — förbered och håll den aktuell

CRA:s tekniska dokumentation är inte ett engångsdokument inför en revision. Artikel 31 kräver att den upprättas innan produkten med digitala element släpps ut på marknaden och uppdateras vid behov, åtminstone under stödperioden.

Om arkitektur, beslut och testresultat måste återskapas från e-post, ärenden och teamets minne är problemet inte en saknad mall. Det är avsaknaden av en produkt- och underlagsmodell som hålls aktuell.

Vad bilaga VII omfattar

Det exakta innehållet beror på produkten, men bilaga VII anger åtminstone följande informationsgrupper.

1. Allmän produktbeskrivning

Den omfattar avsett ändamål, programvaruversioner som påverkar överensstämmelsen med väsentliga cybersäkerhetskrav samt information och instruktioner som lämnas till användarna.

2. Konstruktion, utveckling, produktion och sårbarhetshantering

Dokumentationen ska innehålla tillräcklig information för att förstå konstruktion och arkitektur, sambanden mellan komponenter och tillverkarens processer för sårbarhetshantering.

CRA hänvisar här uttryckligen till SBOM, policyn för samordnad information om sårbarheter, underlag som visar en kontaktadress för sårbarhetsrapportering och de tekniska lösningarna för säker distribution av uppdateringar.

3. Cybersäkerhetsriskbedömning

Dokumentationen ska visa de risker som beaktas när produkten konstrueras, utvecklas, produceras, levereras och underhålls samt hur kraven i bilaga I tillämpas.

4. Grund för stödperioden

Dokumentationen behöver mer än ett slutdatum. Den ska bevara uppgifterna som tillverkaren använde för att fastställa perioden.

5. Använda standarder och tekniska lösningar

När relevanta harmoniserade standarder, gemensamma specifikationer eller cybersäkerhetscertifieringssystem används ska dokumentationen identifiera dem och de tillämpade delarna. När de inte används behöver tillverkaren dokumentera de lösningar som har valts för att uppfylla tillämpliga krav.

6. Testrapporter

Underlag för tester som genomförts för att verifiera produkten och processerna för sårbarhetshantering mot tillämpliga krav.

7. EU-försäkran om överensstämmelse

En kopia av försäkran för produkten.

8. SBOM när en marknadskontrollmyndighet kräver det

Bilaga VII föreskriver att relevant SBOM ska göras tillgänglig efter en motiverad begäran när myndigheten behöver den för att kontrollera överensstämmelsen.

Använd ett index, inte en jättelik PDF

En praktisk modell är ett dokumentationsindex knutet till en produktversion.

Område	Källmaterial	Ansvarig	Version / datum	Granskningsunderlag
avsett ändamål	produktpost	Produktansvarig	v3.4	godkännande
arkitektur	diagram + beskrivning	Utveckling	v3.4	granskning
riskbedömning	riskregister	Säkerhet/Produkt	v3.4	beslut
SBOM	bygg-/utgåveartefakt	Utveckling	utgåva 3.4.2	hash / logg
testning	rapporter	Kvalitetssäkring/Säkerhet	utgåva 3.4.2	resultat
CVD	policy	Säkerhet	rev. 5	godkännande
stödperiod	beslutsdokumentation	Produkt/Ledning	2026-09	motivering

Teknisk dokumentation kan bestå av många artefakter. Det viktiga är att kunna identifiera vilken artefakt som gäller för vilken version och vem som bekräftade att den var aktuell.

Fyra mönster som skapar onödiga kostnader

”Vi har en policy, så detta är täckt”

En policy beskriver hur organisationen avser att arbeta. Den bevisar inte att en viss produktutgåva har bedömts och testats.

”Arkitekturen finns i repot; alla vet var”

Efter en teamförändring eller arton månader är ”alla vet” inte längre en användbar underlagskälla.

”SBOM genereras i pipelinen”

Bra – men dokumentationen måste fortfarande koppla artefakten till produkten, utgåvan och sårbarhetsprocessen.

”Vi exporterar allt före revisionen”

Om källposterna är inkonsekventa visar en export bara inkonsekvensen snabbare.

Hur Pulsar kan organisera dokumentationsspåret

Dokument, underlag, risker, kontroller och rapporter i Pulsar bevarar bedömningarnas kontext. Dokumentationen kan därför fungera som sammanlänkade poster i stället för en mapp som bara innehåller slutliga filer.

Den färdiga posten ska svara på:

vilken produkt och version en artefakt tillhör;
vilket krav eller vilken risk den stödjer;
vem som skapade och godkände den;
när den var aktuell;
vilken åtgärd eller vilket beslut den styrker;
vad som ändrats sedan föregående granskning.

Pulsar tillhandahåller inte skyddat standardinnehåll och ersätter inte tillverkarens tekniska dokumentation. Det hjälper till att upprätthålla struktur, ansvar och spårbarhet.

Se dokument och underlag i Pulsar GRC

En produktutgåva behöver ett identifierbart underlag

Anta att tillverkaren släpper utgåva 3.2 av en uppkopplad produkt. Produktakten ska göra det möjligt att skilja den från 3.1 även om de flesta dokument är gemensamma. Ange vilka komponenter och funktioner som ändrats, vilka riskbedömningar som berörs och vilka tester som verifierar ändringen. Bevara referenser till de handlingar som var aktuella vid beslutet. En länk till senaste arbetsdokument räcker inte om innehållet fortsätter ändras efter utgåvan.

Gör även omfattningen begriplig för någon som inte deltog i utvecklingen. Beskriv vad produkten gör, hur den används och vilka antaganden som ligger bakom bedömningen. Ta med de gränssnitt och fjärrfunktioner som behövs för förståelsen. En lista över teknologier är inte samma sak som en produktbeskrivning. Granskaren behöver se varför en viss funktion eller ett beroende påverkar produktens risk och verifiering.

Ett index med få men meningsfulla fält

Varje dokumentpost bör identifiera artefakten, produktversionen, ansvarig, källdatum och vad dokumentet ska styrka. Lägg också till dess granskningsstatus och en hänvisning till godkännandet. Fälten ska hjälpa teamet att fatta beslut. Om en uppgift inte används för att välja, granska eller återfinna material behöver den kanske inte samlas i registret. Ett enkelt index som underhålls är bättre än ett omfattande index med gamla uppgifter.

Låt originalen finnas i sina kontrollerade källor när det är lämpligt och bevara tillräcklig identifiering för en senare granskning. Om ett testresultat ligger i utvecklingsmiljön behöver produktakten visa exakt vilket resultat och vilken körning som avses. En allmän länk till projektet gör det svårt att förstå det tidigare utgåvebeslutet när projektet har förändrats.

Policyer och produktevidens har olika uppgifter

En policy för sårbarhetshantering beskriver arbetssätt och ansvar. Underlag från ett konkret ärende visar om arbetssättet följdes och vilket resultat det gav. Båda kan behövas, men de ska inte användas som ersättning för varandra. Koppla policyn till relevanta processer och låt ärendets material visa bedömning, åtgärd, test och kommunikation för den berörda versionen.

Samma skillnad gäller arkitektur och verifiering. En designritning visar den avsedda lösningen. Testresultat visar ett observerat beteende under angivna förhållanden. Om testerna bara täcker en konfiguration ska den begränsningen framgå. Ett positivt resultat kan vara korrekt samtidigt som ytterligare konfigurationer behöver bedömas. Produktakten bör göra den skillnaden tydlig så att öppna frågor kan prioriteras.

Dokumentera beslut som inte blev kod

Vissa risker hanteras genom användningsbegränsning, tydligare instruktion eller ett val att inte införa en funktion. Bevara varför alternativet valdes, vilken risk som återstår och vem som godkände beslutet. Ett utvecklingsregister visar ofta bara genomförda ändringar. Utan beslutsunderlaget kan en senare granskare inte se varför ett tidigare förslag avvisades eller när det ska omprövas.

Undvik formuleringar som ”risk accepterad” utan omfattning. Ange vilken version och användningssituation beslutet gäller samt vilka kontroller som förutsätts. En förändring i produkten eller användningen kan kräva ny bedömning. Bevara det gamla beslutet och skapa en ny relation när något ändras. Då kan teamet följa utvecklingen utan att skriva om historiken.

Komponentbyte ska nå dokumentationen

Anta att ett bibliotek uppdateras efter ett sårbarhetsfynd. Den tekniska uppgiften behöver kopplas till komponentförteckningen, riskbedömningen, testresultatet och de utgåvor som berörs. Ange om ändringen gäller hela produkten eller bara en distributionsvariant. Om komponenten även används i andra produkter behöver deras ansvariga veta att en bedömning kan krävas.

Ett dokumentationssteg vid utgåvan bör kontrollera att de berörda artefakterna faktiskt har ändrats. Det räcker inte att utvecklaren markerat koduppgiften som klar. Produktteamet behöver se att den levererade versionen och produktakten beskriver samma innehåll. När full verifiering ännu saknas ska ärendet visa det, tillsammans med beslutad uppföljning och ansvarig.

Granska användarinformation mot verkligt beteende

Instruktioner om installation, konfiguration och uppdatering bör prövas med den version som ska levereras. Be en person följa de relevanta stegen i en lämplig testmiljö. Registrera vilka förkunskaper och behörigheter som behövs. Om en instruktion kräver ett odokumenterat specialsteg ska det rättas eller förklaras. En text som bara fungerar för utvecklingsteamet är svår att använda som kundunderlag.

Kontrollera också om stödperiod och kontaktuppgifter stämmer i olika kanaler. Skillnader mellan användarinformation, avtal och produktakten ska få en ansvarig bedömning. En uppgift som kopierats till många ställen behöver en tydlig källa och en uppdateringsregel. Annars kan den senast rättade versionen leva bredvid flera äldre budskap som användaren fortfarande ser.

Ett mottagningstest för dokumentationspaketet

Välj en risk och låt en oberoende kollega följa den från produktbeskrivning till designbeslut och test. Personen ska hitta rätt artefakt, rätt version och rätt godkännare utan att gissa. Lägg därefter en för gammal testrapport i en separat kopia av paketet. Granskaren ska upptäcka att den inte stöder slutsatsen för aktuell utgåva. Detta är en intern kvalitetskontroll, inte den rättsliga bedömningen av överensstämmelse.

Förklara varför ett dokument avvisas. Det kan vara fel version, otillräcklig omfattning, oklart ursprung eller en slutsats som inte stöds av resultatet. Den informationen hjälper författaren att korrigera paketet och förbättra nästa leverans. Ett generellt avslag med texten ”saknas underlag” gör det svårare att avgöra vad som faktiskt ska ändras.

Delning och arkivering behöver en praktisk kontroll

Öppna paketet i den form mottagaren får. Testa att identifierare och hänvisningar går att följa, att nödvändiga filer finns och att åtkomsten inte kräver en intern behörighet som mottagaren saknar. Bevara den delade versionen och vem som godkände dess omfattning. Kontrollera sekretess och personuppgifter innan innehåll lämnar organisationen. En användbar export är inte samma sak som en tillåtelse att dela allt.

Planera även hur materialet bevaras när utvecklingsverktyg eller leverantörer byts. Produktakten behöver fortfarande kunna förstås efter att en gammal pipeline stängts av. Dokumentera vilka källor som arkiveras och vilken process som kontrollerar att de går att läsa. Om en länk är den enda hänvisningen till ett avgörande resultat behöver teamet bedöma risken att den senare försvinner.

Håll processen användbar för ett litet team

Börja med den produktutgåva där risken eller affärsbehovet är tydligast. Gör dokumentationsgranskningen till en del av de ordinarie utgåvebesluten och fördela ägarskap efter faktisk kunskap. Utvecklaren kan äga testartefakten medan produktansvarig godkänner produktbeskrivningen. Juridiska frågor om tillämplighet och bedömningsförfarande behöver kompetent granskning och ska inte lämnas till en generell AI-sammanfattning.

Pulsar kan ordna dokument, risker, uppgifter och underlag samt bevara deras samband. Det skapar inte saknade tester och ersätter inte tillverkarens tekniska dokumentation. Framsteg innebär att ett verkligt beslut går att förstå och styrka för rätt produktversion. Det är en mer användbar målsättning än att fylla ett visst antal mappar före nästa revision.

Granska dokument som kommer från en tredje part

En leverantörs rapport behöver kopplas till rätt komponent och version i den egna produkten. Kontrollera rapportens omfattning och förutsättningar innan den används som stöd för ett produktbeslut. Ett positivt resultat för leverantörens standardkonfiguration kan vara otillräckligt om organisationen använder komponenten på annat sätt. Dokumentera skillnaden och vad som behöver verifieras separat.

Bevara leverantörens original och den interna bedömningen som skilda handlingar. Om rapporten senare uppdateras ska en ansvarig avgöra om tidigare beslut påverkas. Ändra inte ett godkänt produktpaket genom att tyst byta ut källan. Den tydliga relationen mellan original, bedömning och utgåva hjälper granskaren att förstå vad som faktiskt godkändes.

Relaterad vägledning

Källor

Källor kontrollerade: 2 oktober 2026. De praktiska testerna och exemplen ovan är redaktionella förslag, inte nya rättsliga krav.

Pulsar GRC — åtkomst, dataisolering och export (polska)