CRA:n tekninen dokumentaatio | Tuote, versio ja näyttö

CRA:n tekninen dokumentaatio ei ole kertaluonteinen auditointia varten laadittu asiakirja. Asetuksen 31 artikla edellyttää sen laatimista ennen digitaalisia elementtejä sisältävän tuotteen saattamista markkinoille ja päivittämistä tarpeen mukaan vähintään tukijakson ajan.

Jos arkkitehtuuri, päätökset ja testitulokset on koottava uudelleen sähköposteista, tiketeistä ja tiimin muistista, ongelma ei ole puuttuva mallipohja. Ongelma on ylläpidetyn tuote- ja näyttömallin puuttuminen.

Mitä liite VII kattaa

Tarkka sisältö riippuu tuotteesta, mutta liite VII tunnistaa vähintään seuraavat tietoryhmät.

1. Tuotteen yleiskuvaus

Tähän kuuluvat käyttötarkoitus, olennaisten kyberturvallisuusvaatimusten täyttymiseen vaikuttavat ohjelmistoversiot sekä käyttäjille toimitettavat tiedot ja ohjeet.

2. Suunnittelu, kehitys, tuotanto ja haavoittuvuuksien käsittely

Dokumentaation pitäisi sisältää riittävät tiedot suunnittelun ja arkkitehtuurin, komponenttien suhteiden sekä valmistajan haavoittuvuuksien käsittelyprosessien ymmärtämiseen.

CRA viittaa tässä nimenomaisesti SBOM-luetteloon, koordinoidun haavoittuvuuksien julkistamisen toimintaperiaatteeseen, näyttöön haavoittuvuusilmoitusten yhteysosoitteesta sekä tietoturvapäivitysten turvallisessa jakelussa käytettäviin teknisiin ratkaisuihin.

3. Kyberturvallisuusriskien arviointi

Merkinnän pitäisi osoittaa, mitä riskejä vastaan tuote suunnitellaan, kehitetään, valmistetaan, toimitetaan ja ylläpidetään sekä miten liitteen I vaatimuksia sovelletaan.

4. Tukijakson peruste

Dokumentaatio tarvitsee muutakin kuin päättymispäivän. Sen pitäisi säilyttää tiedot, joita valmistaja käytti tukijakson määrittämiseen.

5. Käytetyt standardit ja tekniset ratkaisut

Kun käytetään asianomaisia yhdenmukaistettuja standardeja, yhteisiä eritelmiä tai kyberturvallisuuden sertifiointijärjestelmiä, dokumentaatio tunnistaa ne ja sovelletut osat. Kun niitä ei käytetä, valmistajan on dokumentoitava ratkaisut, joilla sovellettavat vaatimukset täytetään.

6. Testiraportit

Näyttö testeistä, joilla tuotteen ja haavoittuvuuksien käsittelyprosessien vastaavuus sovellettaviin vaatimuksiin on todennettu.

7. EU-vaatimustenmukaisuusvakuutus

Kopio tuotetta koskevasta vakuutuksesta.

8. SBOM markkinavalvontaviranomaisen sitä vaatiessa

Liitteessä VII säädetään asianomaisen SBOM-luettelon saataville asettamisesta perustellun pyynnön jälkeen, kun se on tarpeen viranomaisen vaatimustenmukaisuuden tarkastusta varten.

Käytä hakemistoa yhden valtavan PDF:n sijaan

Käytännöllinen malli on tuotteen versioon sidottu dokumentaatiohakemisto.

Alue	Lähdeaineisto	Omistaja	Versio / päivämäärä	Näyttö tarkastuksesta
käyttötarkoitus	tuotemerkintä	Tuoteomistaja	v3.4	hyväksyntä
arkkitehtuuri	kaavio + kuvaus	Tekninen tiimi	v3.4	tarkastus
riskinarviointi	riskirekisteri	Tietoturva/tuote	v3.4	päätökset
SBOM	koonti-/julkaisuaineisto	Tekninen tiimi	julkaisu 3.4.2	tiiviste / loki
testaus	raportit	Laadunvarmistus/tietoturva	julkaisu 3.4.2	tulos
CVD	toimintaperiaate	Tietoturva	versio 5	hyväksyntä
tukijakso	päätösmerkintä	Tuote/johto	2026-09	perustelu

Tekninen dokumentaatio voi koostua monesta aineistosta. Olennaista on kyky tunnistaa mikä aineisto koskee mitäkin versiota ja kuka vahvisti sen ajantasaisuuden.

Neljä tarpeetonta kustannusta synnyttävää toimintatapaa

”Meillä on toimintaperiaate, joten asia on katettu”

Toimintaperiaate kuvaa, miten organisaatio aikoo toimia. Se ei osoita, että tietty tuotejulkaisu on arvioitu ja testattu.

”Arkkitehtuuri on repossa, kaikki tietävät missä”

Tiimin muutoksen tai puolentoista vuoden jälkeen ”kaikki tietävät” ei enää ole käyttökelpoinen näytön lähde.

”SBOM luodaan julkaisuketjussa”

Hyvä — mutta dokumentaation on silti liitettävä aineisto tuotteeseen, julkaisuun ja haavoittuvuusprosessiin.

”Viemme kaiken ulos ennen auditointia”

Jos lähdemerkinnät ovat ristiriitaisia, vienti vain paljastaa ristiriidan nopeammin.

Miten Pulsar voi järjestää dokumentaation jäljen

Pulsarin asiakirjat, näyttö, riskit, hallintakeinot ja raportit säilyttävät arviointien asiayhteyden. Näin dokumentaatio voi toimia yhdistettyinä merkintöinä pelkän lopullisia tiedostoja sisältävän kansion sijaan.

Tavoitellun merkinnän pitäisi vastata:

mihin tuotteeseen ja versioon aineisto kuuluu;
mitä vaatimusta tai riskiä se tukee;
kuka loi ja hyväksyi sen;
milloin se oli ajantasainen;
minkä toimen tai päätöksen se osoittaa;
mikä muuttui edellisen tarkastuksen jälkeen.

Pulsar ei toimita suojattua standardisisältöä eikä korvaa valmistajan tuottamaa teknistä dokumentaatiota. Se auttaa ylläpitämään rakennetta, vastuita ja jäljitettävyyttä.

Tutustu asiakirjoihin ja näyttöön Pulsar GRC:ssä

Aiheeseen liittyvät oppaat

Kuvitteellinen julkaisu kolmessa järjestelmässä

Tuotetiimi valmistaa liitetyn laitteen uuden julkaisun. Arkkitehtuuri on repossa, riskiarvio taulukossa ja testit laboratorion portaalissa. Aineisto on olemassa, mutta yhteys julkaisuun puuttuu. Kuukauden päästä tiimi joutuu selvittämään uudelleen, mikä testi tuki päätöstä. Tämä on kuvitteellinen dokumentointiongelma eikä asiakastapauksen selostus.

Määritä julkaisun tunniste ja paketin laajuus. Kuvaa laiteversio, ohjelmisto, tärkeä asetus ja etätoiminto. Määritä henkilö vahvistamaan, että tiedot kuvaavat arvioitua tuotetta. Myyntinimi tai kansio ei yksin riitä. Päätöksen on perustuttava tunnistettavaan todelliseen tuotteeseen ja käyttöön.

Käytä lähteisiin johtavaa indeksiä

Suosittelemamme rekisteri näyttää aineiston tyypin, lähteen, version, omistajan, pääsyn ja tarkastuksen. Alkutiedosto voi jäädä sopivaan tekniseen järjestelmään, jos yhteys on tarkastettava ja aineisto saatavilla. Kaikkea ei tarvitse kopioida yhteen PDF:ään. Pitää kuitenkin tietää, mitä viite osoittaa ja mille julkaisulle.

Erota päätöstä tukeva näyttö taustasta. Yleinen rakennekuva voi auttaa lukijaa mutta ei näyttää uuden liitännän riskiratkaisua. Testisuunnitelma kuvaa aikomusta, testitulos tehtyä tarkastusta. Jos molemmat on nimetty vain ”testiasiakirjaksi”, keskeneräinen työ voi jäädä piiloon. Selvä nimeäminen tukee sisällöllistä arviointia.

Perustele vaatimuksen ja näytön yhteys

Olennaisen johtopäätöksen kohdalla näytä vaatimus tai riski ja sitä tukeva aineisto. Yksi yleinen turvatesti ei automaattisesti kata kaikkea. Raportti voi koskea tiettyä liitäntää ja asetusta. Arvioijan tulee tuntea ulottuvuus ennen valmista merkintää, jotta paketti ei lupaa enempää kuin testattiin.

Osittainen näyttö voi olla oikein ja hyödyllinen. Säilytä sen raja ja tarvittava lisätehtävä. Ongelma on täydellisenä esittäminen ilman perustetta. Arvioija tarkistaa johtopäätöksen suhteen aineistoon eikä vain tiedoston olemassaoloa. Näin suuresta kansiosta ei tule perusteettoman varmuuden lähdettä.

Liitä riskiarvio oikeaan julkaisuun

Riskin tulee kuvata päätöksen tuotetta ja käyttöä. Rakenne voi muuttaa hyökkäyspintaa, riippuvuuksia tai oikeuksia. Merkitse muuttunut oletus ja sen tarkastus. Jos arvio ei muutu, perustele miksi uusi julkaisu ei vaikuta siihen. Vanhan aineiston kopiointi ei ole vaikutusten arviointia.

Säilytä hyväksyjän nimi tai rooli, aika ja lähteet. Jos lähde muuttuu myöhemmin, historiallinen päätös pysyy ymmärrettävänä. Älä korvaa aiempaa versiota huomaamatta. Yrityksen pitää pystyä kertomaan, mitä julkaisun päättäjä todella tiesi silloin. Nykyinen arvio ei ole automaattisesti sama tieto.

Testiraportti tarvitsee laatukontrollin

Tarkista testattu tuote, ympäristö, aika, menetelmä, tulos ja rajat. Pätevän laboratorion raportti voi koskea eri laitetta. Tekninen arvioija ratkaisee eron merkityksen. Toisen version raportin liittäminen ei tee siitä uuden version näyttöä. Näytä tarvittava lisätesti tai perusteltu soveltuvuuden päätös.

Myös epäonnistunut testi voi kuulua rekisteriin. Se näyttää puutteen ja uuden kokeen tarpeen. Liitä epäonnistuminen tehtävään ja myöhempään tulokseen. Arvioija näkee silloin muutoksen sekä hyväksymisen perusteen. Pelkkä viimeinen vihreä raportti voi hävittää tärkeän päätöshistorian ja vaikeuttaa myöhempää selvitystä.

SBOM ja käsittely kuuluvat elinkaareen

Komponenttiluettelon tulee liittyä julkaisuun ja sen rajaus on tunnettava. Haavoittuvuuksien prosessi kertoo tiedon saapumisen, vaikutusarvion, vastuun ja korjauksen testin. Politiikka ei osoita, että tapaus toimii käytännössä. Kokeile prosessia harjoituksella tai tarkasta jo käsitelty tapaus oikeine aineistoineen.

Riippuvuuden tuen muutos voi vaikuttaa dokumentaation muuhun osaan. Yhdistä tieto tukijakson perusteluun ja määrää tarkastus. Rekisteri auttaa löytämään päätökset, mutta tekninen ja oikeudellinen arvio jää ihmiselle. Tekoäly ei hyväksy poikkeusta tai riskin lopullista ratkaisua organisaation puolesta.

Määritä pääsy ennen jakamista

Teknisessä aineistossa voi olla liikesalaisuuksia, arkaluonteista turvatietoa ja henkilötietoja. Päätä vastaanottajan tarvitsemat materiaalit ja peruste. Yksi julkinen linkki koko kansioon ei ole oletusarvoisesti sopiva. Käytä rajattua pakettia tarpeen mukaan ja säilytä yhteys alkuperäiseen aineistoon hallitusti.

Kokeile näkymää vastaanottajan oikeuksilla. Omistaja voi nähdä tiedoston, jota ulkoinen lukija ei avaa. Paketti voi myös näyttää toisen asiakkaan tiedot monen projektin kansiosta. Tarkista molemmat ennen lähettämistä. Käytettävyys ja luottamuksellisuus tarvitsevat huomion samaan aikaan, eivät eri projektien loppuvaiheissa.

Määritä päivityksen käynnistävä tapahtuma

Uusi julkaisu, tärkeä rakennemuutos, käyttötarkoitus, korjaus tai tuen oletus voi vaatia tarkastuksen. Kohdista se vaikuttuneisiin osiin. Koko paketin kopiointi uuteen kansioon voi vain monistaa vanhan virheen. Tarkastus tarvitsee sisällöllisen päätöksen siitä, mikä edelleen tukee tuotetta.

Kirjaa muutos, uusi näyttö ja ennallaan säilyvät perustellut osat. Hyväksy rekisterin uusi versio ja säilytä tarpeellinen historia. Näin voidaan vastata tietystä markkinoille annetusta julkaisusta eikä vain näyttää uusinta aineistoa. Vanha julkaisu voi olla edelleen käytössä, vaikka dokumentointityö jatkuu uuteen.

Hyväksymistesti ilman tekijän apua

Anna rekisteri pätevälle henkilölle, joka ei koonnut pakettia. Pyydä tuotteen kuvaus, riski, yhden suojan testi, SBOM, tuen peruste ja julkaisun päätös. Hänen pitää selittää, miksi aineisto kuuluu juuri tähän tuotteeseen. Jos vastaus tarvitsee tekijän muistia, täydennä yhteydet.

Pulsar voi jäsentää aineistot, tehtävät, riskit ja päätöshistorian. Se ei korvaa valmistajan dokumentaatiota eikä anna suojattua standarditekstiä. Tarkista nykyinen palvelulaajuus ennen työnkulun rakentamista. Työtesti ei takaa sertifiointia tai täydellistä vaatimustenmukaisuutta, vaan osoittaa rajatun paketin käytettävyyttä.

Paketin indeksin esimerkki

Aineisto	Version perusta	Vastaanoton ehto
Tuotekuvaus	todella toimitettu kokoonpano	lukija tunnistaa arvioidun tuotteen
Riskiarvio	rakenne ja käyttötarkoitus	faktat ja päätelmät erottuvat
Testitulokset	testattu julkaisu ja ympäristö	tulos tukee nimettyä käyttäytymistä
SBOM	rakennettu artefakti ja luettelon rajaus	osa liittyy oikeaan versioon
Tuen peruste	käyttö ja tärkeät riippuvuudet	päivämäärän syy on tarkastettava
Haavoittuvuuskäytäntö	omistajat ja toimintavaiheet	koe osoittaa todellisen järjestelyn
Loppuarvio	hyväksytty indeksiversio	avoimet puutteet eivät katoa yhteenvedosta

Tämä indeksi on työehdotus eikä täydellinen viranomaismalli. Organisaatio tarkistaa asetuksen sisällön ja oman tuotteensa tarpeen. Määritä tärkeille riveille pätevä arvioija. Yksi henkilö voi kantaa useita rooleja, mutta hänen pitää tietää, mitä hän vahvistaa ja mitä vain kokoaa. Koonti ei automaattisesti ole sisällön hyväksyntä.

Säilytä viitteen käyttämä versio

Repohaara voi siirtyä eteenpäin ja pilvikansio saada uuden sisällön. Merkittävä näyttö tarvitsee yhteyden käytettyyn versioon. Nykyiseen tiedostoon johtava linkki ei välttämättä näytä aiemman päätöksen aineistoa. Valitse ympäristölle sopiva tapa säilyttää tunnistettavuus ja varmista se kokeella. Tarkka tekniikka riippuu käytetystä lähdejärjestelmästä.

Historiallinen versio voi tukea tietyn toimituksen tarkastusta, vaikka nykyinen ohje on uudempi. Määritä ero selvästi. Käyttäjä ei saa vahingossa ottaa arkistosta vanhaa ohjetta nykyiseen käyttöön, mutta arvioijan pitää silti voida tutkia aiempaa päätöstä. Pääsyn, nimeämisen ja version tilan järjestely ratkaisee molemmat tarpeet yhdessä.

Kokeile vastuun vaihtumista

Uuden omistajan tulee löytää indeksi, ymmärtää oikeudet ja nähdä avoimet tehtävät. Jos henkilökohtainen tili tai muistikirja pitää koko asiayhteyden, aineisto on yhä riippuvainen yhdestä ihmisestä. Määritä tarkka puuttuva tieto ja siirrä se hallittuun paikkaan. Pelkkä kansioiden omistajan vaihtaminen ei takaa merkityksen säilymistä.

Anna kokeessa uudelle henkilölle yksi ulkoinen kysymys ja normaali työohje. Hän löytää tarvittavan aineiston sekä sen hyväksynnän. Arvioi myös, pystyykö hän tunnistamaan väärän version. Tiedoston avaaminen yksin on heikko koe. Oikea johtopäätös ja sen lähde näyttävät dokumentaation käytettävyyden paremmin kuin iso löydettyjen liitteiden määrä.

Standardin lisenssi rajaa jakamista

Säilytä normiviite ja organisaation käyttöoikeuden ehdot. Julkisen paketin ei tule sisältää suojatun standardin täyttä kopiota. Standardin sisäinen käyttö ja sen ulkoinen julkaiseminen ovat eri kysymyksiä. Pulsar ei anna tekijänoikeuslupaa. Organisaatio toimittaa oman sallitun aineiston ja määrittää pääsyn todellisen lisenssin perusteella.

Myös asiakkaan oma aineisto voi olla luottamuksellista ilman standardilisenssiä. Tarkista sopimus sekä jakamisen tarkoitus. Jos tarvitaan rajattu kopio, säilytä linkki alkuperäiseen ja kerro rajaus arvioijalle. Näytön tarpeellinen merkitys ei saa kadota, mutta sivullisen projektin tietoa ei tarvitse antaa mukaan. Tämä päätös tehdään ennen lähetystä eikä vasta vastaanottajan kysymyksestä.

Kokeile vientiä pienellä paketilla

Älä odota loppuun viennin luettavuuden tarkastusta. Kokoa rajattu esimerkki ja pyydä toista henkilöä käyttämään sitä ilman alkuperäistä käyttöliittymää. Säilyvätkö yhteydet, ajat ja avoimet kysymykset? Jos eivät, täsmennä tuloste tai työnkulku ennen laajaa käyttöönottoa. Viennin tekninen olemassaolo ei vielä osoita soveltuvuutta organisaation tarpeeseen.

Tarkista myös tiedostojen nimet ja hakemiston rakenne. Vastaanottaja voi nähdä monta samannimistä raporttia ilman versiota. Yksinkertainen nimeämisratkaisu voi auttaa enemmän kuin pitkä selitys. Älä kuitenkaan muuta alkuperäistä testin identiteettiä niin, ettei sitä voi enää verrata lähdejärjestelmään. Säilytä alkuperäinen tunnus ja tarvittava selventävä nimi rinnakkain.

Lopullisen arvion raja

Paketin sisäinen hyväksyntä kertoo arvioidun aineiston sekä päätöksen. Se ei ole yleinen lupaus tuotteen turvallisuudesta. Jos tekninen kysymys jäi auki, näytä se ja seuraava tehtävä. Rehellinen rajaus antaa johdolle mahdollisuuden tehdä perusteltu jatkoratkaisu. Näyttävän yhteenvedon tehtävä on kertoa oikea tila, ei peittää dokumentaation vielä tuntemattomia osia.

Lähteet

Lähteet tarkistettu: 2. lokakuuta 2026.

Pulsar GRC — pääsy, tietojen eristäminen ja vienti (puolaksi)