CRA 2026: produktsikkerhedsfil med ISO 27001

En producent af forbundne enheder indkalder sin CISO, Maria, til et møde fredag eftermiddag. Salgsafdelingen har netop sikret en europæisk distributionsaftale. Juridisk afdeling spørger, om virksomheden kan understøtte overensstemmelse med Cyber Resilience Act. Engineering siger, at sikker udvikling “for det meste er dækket”, fordi der findes kodegennemgang, SAST og patching. Indkøb siger, at leverandørerne er “underlagt NDA”. Produktteams har firmwareafhængigheder i ét værktøj, fortegnelser over cloud-API’er i et andet og sårbarhedssager i Jira. Compliance har ISO/IEC 27001:2022-certificeringsevidens, men den er organiseret omkring virksomhedens ISMS og ikke omkring hvert enkelt produkt, der bringes i omsætning på EU-markedet.

Så kommer det ubehagelige spørgsmål: “Hvis en EU-myndighed, en kunde, et notificeret organ eller en stor distributør beder om produktsikkerhedsfilen i 2026, kan vi så fremlægge den inden for én uge?”

For mange softwareleverandører, producenter af intelligente enheder og udbydere af forbundne tjenester er det ærlige svar nej. Ikke fordi de mangler sikkerhedskontroller, men fordi deres produktsikkerhedsevidens er spredt. Registreringer om sikker udvikling ligger hos engineering. SBOM’er genereres pr. build, men er ikke underlagt governance. Koordineret offentliggørelse af sårbarheder findes som en webside, men er ikke altid forbundet med triage, rettelser, sikkerhedsmeddelelser og post-market-overvågning. Leverandørsikkerhed ligger begravet i indkøbskontrakter. Hændelsesrapportering hører til i sikkerhedsdriften, mens overensstemmelsesdokumentation hører til i produktoverensstemmelse.

EU’s Cyber Resilience Act ændrer driftsmodellen. Produkters cybersikkerhed er ikke længere kun bedste praksis eller et kontraktligt løfte. Det bliver en livscyklusbaseret dokumentationsforpligtelse. Organisationer skal kunne vise, hvordan cybersikkerhedskrav er indbygget i design, udvikling, release, sårbarhedshåndtering, opdateringer og overvågning, efter at produktet er bragt i omsætning.

Det er her, ISO/IEC 27001:2022 bliver stærk, hvis standarden anvendes korrekt. Den er ikke i sig selv en produktcertificeringsordning, men dens ISMS og kontroller for risiko, aktiver, leverandører, sikker udvikling, sårbarheder og hændelser kan udgøre rygraden i en CRA-produktsikkerhedsfil. Målet er ikke at skabe endnu en compliance-silo. Målet er at omsætte jeres eksisterende ISMS til et evidenssystem på produktniveau.

Som Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap formulerer det i fase 2, trin 8, evidensarkitektur:

“Evidens bør ikke indsamles ved afslutningen af auditcyklussen. Den bør designes ind i kontrollen, tildeles en ejer, tidsstemples af processen og kunne genbruges på tværs af alle forpligtelser, der stiller det samme spørgsmål med forskellige ord.”

Den sætning indfanger kernen i CRA-beredskab. Spørgsmålet er ikke kun: “Har vi sikker udvikling?” Spørgsmålet er: “Kan vi dokumentere sikker udvikling, komponentoverblik, sårbarhedshåndtering og post-market-overvågning for dette produkt, denne version, denne release og dette marked?”

CRA-produktsikkerhedsfilen er et levende evidenssystem

En CRA-produktsikkerhedsfil bør ikke behandles som en statisk PDF, der udarbejdes én gang før release og derefter glemmes. Den bør være et struktureret dossier, der fortæller produktets sikkerhedshistorik fra koncept til supportophør.

En anvendelig fil forklarer:

1. Hvad produktet er, og hvordan det er tiltænkt anvendt.
2. Hvilken software, firmware, cloudtjenester og tredjepartsafhængigheder det omfatter.
3. Hvilke cybersikkerhedsrisici der er vurderet.
4. Hvilke sikkerhedskrav der er anvendt.
5. Hvordan sikker udvikling er gennemført.
6. Hvordan sårbarheder modtages, triageres, rettes og offentliggøres.
7. Hvordan sikre opdateringer leveres.
8. Hvordan leverandører og open source-komponenter kontrolleres.
9. Hvordan hændelser og aktivt udnyttede sårbarheder eskaleres.
10. Hvordan produktet overvåges efter markedsføring.

For en CISO er dette en ISMS-udfordring vedrørende evidens. For en ansvarlig for produktoverensstemmelse er det teknisk dokumentation. For engineering er det DevSecOps og release-governance. For topledelsen er det markedsadgang og ansvarsstyring.

Fejlen er at behandle disse som adskilte arbejdsstrømme. Den bedre model er at opbygge en evidensfil på produktniveau, der kortlægges til ISO/IEC 27001:2022- og ISO/IEC 27002:2022-kontroller, og derefter krydskortlægge den samme evidens til NIS2, DORA, GDPR, NIST og COBIT 2019, hvor det er relevant.

Clarysecs Zenith Controls: The Cross-Compliance Guide beskriver dette som en kæde fra kontrol til evidens til auditor:

“En evidensfil til tværgående efterlevelse bør kortlægge hver forpligtelse til den operationelle kontrol, det tilbagevendende evidensobjekt, den ansvarlige ejer og den revisionsvinkel, der vil blive brugt til at udfordre den.”

Det er den disciplin, CRA-forberedelse kræver. Produktsikkerhedsfilen er ikke blot en mappe. Den er oversættelseslaget mellem produktudvikling, sikkerhedsstyring, overensstemmelsesvurdering og kundedokumentation.

Opbyg først produktets evidensrygrad

Filen skal have en ensartet struktur, før teams begynder at uploade registreringer. Uden en tydelig rygrad bliver evidens til en bunke screenshots, eksportfiler og politik-PDF’er, som ingen auditor kan følge.

Til CRA-beredskabsworkshops anbefaler Clarysec typisk følgende struktur for produktsikkerhedsfilen til organisationer, der allerede driver et ISO/IEC 27001:2022-ISMS.

Denne tabel erstatter ikke retlige forpligtelser til teknisk dokumentation. Den giver forretningen en driftsmodel til at dokumentere dem.

I Zenith Blueprint fokuserer fase 1, trin 3 på definition af omfang og afgrænsning. For CRA bliver dette trin produktspecifikt. Definér produktfamilien, softwareversioner, implementeringsforudsætninger, brugerroller, forbundne tjenester, opdateringskanaler og supportperiode. Hvis ISMS-omfanget er “Corporate SaaS and device management platform”, skal CRA-filen stadig besvare et snævrere spørgsmål: “Hvilket produkt med digitale elementer bringes i omsætning på EU-markedet, og hvad indgår i dette produkt?”

Kortlæg sikker udvikling til registreringer på produktniveau

Kernen i produktsikkerhedsfilen er evidens for security by design. ISO/IEC 27001:2022 leverer ledelsessystemet. ISO/IEC 27002:2022 giver implementeringsvejledning gennem kontroller som A.8.25 Sikker udviklingslivscyklus, A.8.27 Sikker systemarkitektur og tekniske principper, A.8.28 Sikker kodning og A.8.29 Sikkerhedstest i udvikling og godkendelse.

Den væsentlige ændring er at gå fra generelle påstande om sikker udvikling til release-specifikke registreringer. “Vi udfører kodegennemgang” er ikke nok. Filen bør vise, hvilken release der blev gennemgået, hvilke risici der blev vurderet, hvilke sikkerhedstest der blev bestået, hvilke sårbarheder der blev accepteret eller afhjulpet, og hvem der godkendte releasen.

Clarysecs Enterprise Secure development policy er udformet til at fremtvinge dette revisionsspor. I klausul 6.1, Secure Development Lifecycle Requirements, står der:

“Hver produkt- eller tjenesterelease skal opretholde dokumenteret evidens for sikkerhedskrav, designgennemgang, aktiviteter for sikker kodning, sikkerhedstest, beslutninger om afhjælpning af sårbarheder og releasegodkendelse før idriftsættelse i produktionsmiljøet.”

Denne klausul er nyttig for CRA, fordi den gør sikker udvikling til et gentageligt evidensmønster. En auditor behøver ikke udlede, at sikker udvikling er gennemført. Vedkommende kan inspicere release-registreringen.

For en intelligent termostat, medicinsk IoT-enhed, industriel sensor eller SaaS-forbundet produkt bør evidens for sikker udvikling omfatte:

• Produktsikkerhedskrav kortlagt til identificerede risici.
• Trusselsmodel eller abuse case-analyse for produktet og forbundne tjenester.
• Arkitekturgennemgang, herunder tillidsgrænser og eksterne grænseflader.
• Standard for sikker kodning og dokumentation for udviklernes bekræftelse eller uddannelse.
• SAST, DAST, Software Composition Analysis, secrets scanning og firmwareanalyse, hvor det er relevant.
• Afhjælpningssager for højrisikokonstateringer.
• Registreringer af risikoaccept med godkendelse fra forretning og sikkerhed.
• Release gate-tjekliste, der viser, at sikkerhedskriterierne er opfyldt.
• Evidens for kryptografisk signering og opdateringsintegritet.
• Forudsætninger om supportperiode og end-of-life.

Andre standarder styrker metoden. ISO/IEC 27005 understøtter risikotilgangen bag disse registreringer. ISO/IEC 27017 er nyttig, når cloudtjenester indgår i produktøkosystemet. ISO/IEC 27035 understøtter håndtering af hændelser. ISO/IEC 29147 og ISO/IEC 30111 er særligt relevante for offentliggørelse af sårbarheder og sårbarhedshåndtering. ISO/IEC 27036 understøtter leverandørsikkerhed, hvilket er vigtigt, når produktet omfatter outsourcet software, indlejrede moduler, administrerede cloudtjenester eller tredjepartsbiblioteker.

I Zenith Controls kortlægges CRA-evidens for sikker udvikling normalt omkring kontroltemaer i ISO/IEC 27002:2022 såsom informationssikkerhed i projektledelse, sikker udviklingslivscyklus, sikker kodning, sikkerhedstest, ændringsstyring og styring af tekniske sårbarheder. Guiden forbinder også disse med aktivfortegnelse og leverandørkontroller, fordi ingen sikker udviklingsproces er komplet, hvis organisationen ikke kan identificere de komponenter, den leverer med produktet.

Behandl SBOM som reguleret produktevidens

Software Bill of Materials behandles ofte som en teknisk artefakt. I CRA-beredskab bør den behandles som produktevidens.

En anvendelig SBOM viser, hvilke komponenter der er i produktet, hvilke versioner der anvendes, hvor de kommer fra, hvilke licenser der gælder, hvilke sårbarheder der påvirker dem, og hvilke releases de indgår i. For firmware og indlejrede produkter kan dette omfatte operativsystempakker, bootloadere, biblioteker, drivere, containere, tredjepartsmoduler og cloud-side-afhængigheder, der er nødvendige for produktets drift.

Problemet er, at mange organisationer genererer SBOM’er, men ikke styrer dem. En build-pipeline kan producere en SPDX- eller CycloneDX-fil, men ingen validerer fuldstændigheden. Sikkerhedsværktøjer kan markere sårbarheder, men resultaterne er ikke bundet til produktversioner. Indkøb kan godkende en leverandør, men leverandørens komponentliste afstemmes ikke med det frigivne produkt.

Clarysecs Enterprise Asset management policy adresserer dette governance-hul i klausul 5.2, Information and Associated Asset Inventory:

“Informationsaktiver og tilknyttede teknologikomponenter skal identificeres, tildeles en ejer, klassificeres hvor relevant og vedligeholdes i en fortegnelse, der understøtter risikovurdering, sårbarhedsstyring, ændringsstyring og revisionsbevis.”

For CRA bliver denne klausul produktspecifik. SBOM’en er en del af fortegnelsen over tilknyttede teknologikomponenter. Den skal have en ejer, en opbevaringsregel, en valideringsproces og en kobling til sårbarhedsstyring.

En praktisk SBOM-evidensregel er enkel: Hver frigivet produktversion skal have en godkendt komponentfortegnelse, der kan matches med release-artefaktet. Hvis organisationen ikke kan forbinde SBOM’en med det nøjagtige firmware-image, applikationspakke, container-digest eller SaaS-release, er SBOM’en svag evidens.

Hvis mere end to rækker fejler, er problemet som regel ikke SBOM-værktøjet. Det er governance. Produktsikkerhedsfilen bør registrere en korrigerende handling i ISMS’et, fordi svagheder i CRA-evidens også er et problem med kontroleffektivitet efter ISO/IEC 27001:2022.

Forbind CVD med sårbarhedshåndtering og release-governance

Koordineret offentliggørelse af sårbarheder er et af de mest synlige områder i CRA-beredskab, fordi eksterne sikkerhedsforskere, kunder og myndigheder kan teste det direkte. Det er nyttigt at offentliggøre en side om sårbarhedsrapportering eller en security.txt-fil, men det er kun fordøren. Produktsikkerhedsfilen skal dokumentere, at backoffice-processen fungerer.

Et forsvarligt evidenssæt for CVD og sårbarhedshåndtering bør omfatte:

• Offentligt tilgængelig kanal for offentliggørelse og indsendelsesinstruktioner.
• Proces for bekræftelse til sikkerhedsforskere.
• Triagekriterier, herunder vurdering af alvorlighed og udnyttelighed.
• Analyse af produktpåvirkning.
• Ejerskab til afhjælpning og målfrister.
• Skabeloner til kundemeddelelser og opdateringskommunikation.
• Evidens for sikker patchudvikling og test.
• Registreringer af koordineret offentliggørelse, hvor relevant.
• Læring og analyse af tilbagevendende sårbarhedstendenser.

Clarysecs Enterprise Vulnerability management policy, klausul 6.3, Vulnerability Intake, Triage and Remediation, angiver:

“Rapporterede sårbarheder skal logges, vurderes for berørte aktiver og produkter, prioriteres efter risiko og udnyttelighed, tildeles en ansvarlig ejer og spores gennem afhjælpning, verifikation, kommunikation og lukning.”

Denne klausul forbinder CVD med SBOM, aktivfortegnelse, engineering-sager, release-styring og post-market-overvågning. Det er også den klausul, auditorer naturligt vil teste: Vis modtagelsesregistreringen, vis de berørte produkter, vis triagen, vis rettelsen, vis kundekommunikationen, vis lukningen.

Jeres eksisterende Information Security Incident Management Policy bør også udvides til at dække produktsårbarheder, der bliver til hændelser eller kræver ekstern underretning. ISO/IEC 27002:2022 A.5.24 dækker planlægning og forberedelse af hændelsesstyring, A.5.25 dækker vurdering af og beslutning om informationssikkerhedshændelser, A.5.26 dækker reaktion på informationssikkerhedshændelser, og A.5.27 dækker læring fra hændelser.

I Zenith Controls behandles sårbarhedsstyring som både forebyggende og korrigerende. Den forebyggende side omfatter fortegnelse, sikker udvikling, leverandørovervågning og sikker konfiguration. Den korrigerende side omfatter detektion, triage, patching, kommunikation og hændelseseskalering. Denne skelnen er vigtig, fordi post-market-sårbarhedshåndtering er en del af produktets livscyklusforpligtelse, ikke en eftertanke.

Leverandørevidens er den skjulte svaghed

Produktsikkerhedsfilen vil ofte blive udfordret hårdest der, hvor producenten er afhængig af andre. Det omfatter indlejrede moduler, outsourcet firmwareudvikling, white label-komponenter, cloudhosting, mobile SDK’er, betalingstjenester, kryptografiske biblioteker og managed supportudbydere.

Det typiske fejlmønster er kontraktlig abstraktion. Producenten siger: “Vores leverandør er ansvarlig for det.” Under granskning af produktsikkerhed er det ikke nok. Organisationen skal vise, at leverandørrisiko er identificeret, sikkerhedskrav er kommunikeret, evidens er indsamlet, sårbarheder koordineres, og ændringer kontrolleres.

Clarysecs Enterprise Third-party and supplier security policy, klausul 7.1, Supplier Security Requirements, angiver:

“Leverandører, der udvikler, driver, behandler, understøtter eller væsentligt påvirker informationssystemer, produkter eller tjenester, skal vurderes efter risiko og underlægges sikkerhedskrav, der dækker adgang, sårbarhedsstyring, hændelsesunderretning, underleverandører, kontinuitet og levering af evidens.”

For CRA er formuleringen “væsentligt påvirker produkter” afgørende. Hvis en leverandørkomponent kan introducere en sårbarhed, forstyrre opdateringer, eksponere kundedata eller kompromittere enheds integritet, hører den hjemme i produktsikkerhedsfilen.

Den samme politik kan også understøtte SBOM-kontraktkrav. Klausul 7.3 angiver:

“For alle tredjepartssoftwarekomponenter, biblioteker eller operativsystemer, der skal integreres i virksomhedens produkter med digitale elementer, skal leverandøren efter anmodning levere en maskinlæsbar Software Bill of Materials (SBOM) i et standardformat såsom SPDX eller CycloneDX. Dette krav skal indarbejdes i alle indkøbs- og leverandørkontrakter.”

En stærk leverandørevidenspakke bør omfatte leverandørklassificering efter produktpåvirkning, sikkerhedskrav i kontrakter, leverandørens evidens for sikker udvikling for kritiske komponenter, leverandørforpligtelser om offentliggørelse af sårbarheder, SBOM eller komponenterklæringer hvor muligt, patchsupport og end-of-life-tidslinjer, periodiske gennemgangsregistreringer og eskalationsveje for sårbarheder med oprindelse hos leverandører.

ISO/IEC 27002:2022 A.5.19, A.5.20 og A.5.21 giver de centrale leverandørkontroltemaer. ISO/IEC 27036 giver større dybde om sikkerhed i leverandørrelationer. I tværgående efterlevelse lægger NIS2 vægt på forsyningskæden og sårbarhedshåndtering. DORA lægger vægt på IKT-tredjepartsrisiko for finansielle enheder. GDPR bliver relevant, når produktet eller dets cloudtjenester behandler personoplysninger. COBIT 2019 rammesætter leverandørstyring som et spørgsmål om styring af virksomhedsteknologi, ikke kun et spørgsmål for sikkerhedsdriften.

Post-market-overvågning omsætter evidens til drift

De mest modne produktsikkerhedsorganisationer tænker ud over release. De spørger: “Hvordan opdager vi, at dette produkt er blevet risikabelt, efter at det er taget i brug hos kunderne?”

Post-market-overvågning bør indsamle signaler fra sårbarhedsfeeds, exploit intelligence, kundesupport, telemetri, bug bounty- eller sikkerhedsforsker-rapporter, leverandørunderretninger, cloudlogfiler, hændelsesregistreringer og feltdata om performance. Den bør også omfatte periodisk gennemgang af produktrisiko, når trusselsbilledet ændrer sig.

Clarysecs Enterprise Logging and monitoring policy, klausul 5.4, Security Monitoring and Review, angiver:

“Sikkerhedsrelevante hændelser skal indsamles, gennemgås, eskaleres og opbevares på en måde, der understøtter rettidig detektion, undersøgelse, hændelseshåndtering, efterlevelsesrapportering og løbende forbedring.”

For forbundne produkter skal dette fortolkes omhyggeligt. Overvågning skal respektere privatliv, dataminimering og retlige begrænsninger, især hvor telemetri omfatter personoplysninger eller kunders driftsdata. GDPR-kortlægning er vigtig. Produktsikkerhedsteams bør samarbejde med databeskyttelsesteams om at definere, hvilken telemetri der er nødvendig for sikkerhed, hvordan den minimeres, hvor længe den opbevares, og hvordan kunder informeres.

Evidens for post-market-overvågning bør omfatte en overvågningsplan for produktsikkerhed, kilder til sårbarhedsintelligens, kanaler til modtagelse af kunderapporter, leverandørunderretningskanaler, omfang for gennemgang af telemetri eller logfiler, referater fra periodiske produktrisikogennemgange, sporing af patchadoption, analyse af hændelsestendenser og input til ledelsens gennemgang.

I Zenith Blueprint fokuserer fase 5, trin 30 på løbende forbedring og beredskab til overvågning. For CRA er det her, produktsikkerhedsfilen bliver en levende fil. Hver produktrelease, sårbarhed, leverandørændring og feltsignal bør opdatere evidensregistreringen.

Én evidensfil, mange efterlevelsesspørgsmål

En veldesignet CRA-produktsikkerhedsfil reducerer dobbeltarbejde, fordi den samme evidens besvarer flere efterlevelsesspørgsmål. Sproget ændrer sig, men kontrolrealiteten er ofte den samme.

Zenith Controls er designet til dette genbrug. Den kortlægger kontroltemaer i ISO/IEC 27002:2022 til attributter som forebyggende, detekterende og korrigerende kontrolformål, cybersikkerhedskoncepter, operationelle kapabiliteter og sikkerhedsegenskaber. For CRA hjælper dette en CISO med at forklare, hvorfor ét evidensobjekt, f.eks. en sikkerhedsgennemgang af en release, understøtter sikker udvikling, risikobehandling, ændringsstyring, sårbarhedsstyring og revisionsberedskab.

Forbered jer på forskellige revisionsvinkler

En CRA-produktsikkerhedsfil kan blive udfordret af en ISO-auditor, intern revision, et kundesikkerhedsteam, en produktkonformitetsvurderer, en tilsynsmyndighed, en NIST-baseret assessor eller en ISACA-uddannet COBIT-auditor. De vil stille lignende spørgsmål gennem forskellige vinkler.

Det samme svage punkt vil blive eksponeret forskelligt. Hvis SBOM’er genereres, men ikke opbevares, ser ISO-auditoren et problem med registreringsstyring og operationelle kontroller. NIST-assessoren ser en svaghed i styring af aktiver og sårbarheder. COBIT-auditoren ser svag governance over informationsaktiver. Produktvurdereren ser utilstrækkelig teknisk dokumentation.

En 30-trins køreplan tilpasset CRA-beredskab

Zenith Blueprint forhindrer compliance-teams i at springe direkte til dokumentindsamling. For CRA bliver 30-trins køreplanen til et evidensprogram for produktsikkerhed.

Fase 1 begynder med kortlægning af forpligtelser og omfang. Identificér, hvilke produkter, versioner, komponenter, cloudtjenester og supportprocesser der er omfattet. Bekræft tilsigtet brug, brugerkategorier, markeder og supportperiode for sikkerhed.

Fase 2 opbygger evidensarkitekturen. Definér indeks for produktsikkerhedsfilen, ejere af evidens, opbevaringskrav, repositorystruktur og godkendelsesworkflow. Afstem med engineering-systemer i stedet for at gennemtvinge manuelle uploads.

Fase 3 implementerer operationelle kontroller. Sikker udvikling, SBOM-generering, sårbarhedshåndtering, leverandørevidens, release gates, sikre opdateringer og hændelseseskalering skal fungere som reelle processer.

Fase 4 tester revisionsberedskab. Vælg en produktrelease og gennemfør en simuleret audit. Kan teamet finde SBOM’en? Kan de dokumentere sikkerhedstest? Kan de vise, hvordan en sårbarhed blev triageret? Kan de forbinde leverandørevidens med produktkomponenter?

Fase 5 indarbejder overvågning og forbedring. Post-market-overvågning, analyse af sårbarhedstendenser, leverandørgennemgange og input til ledelsens gennemgang holder filen ajour.

Dette sprint afslører normalt sandheden hurtigt. Organisationer fejler sjældent, fordi de mangler alle kontroller. De fejler, fordi kontrollerne ikke er forbundet på produktniveau.

Almindelige CRA-beredskabsmangler før 2026

På tværs af softwareleverandører, enhedsproducenter og udbydere af forbundne tjenester er de tilbagevendende mangler konsistente.

For det første er ISMS-omfanget for virksomhedsorienteret. Det dækker organisationen, men ikke tilstrækkelige detaljer om produktlivscyklussen. Løsningen er at oprette bilag og evidensfiler på produktniveau.

For det andet findes SBOM’er, men de er ikke troværdige. De genereres af værktøjer, men gennemgås, godkendes, opbevares eller forbindes ikke med sårbarhedsbeslutninger. Løsningen er SBOM-governance, ikke kun SBOM-produktion.

For det tredje er CVD offentligt synlig, men ikke operationelt moden. Rapporter kommer ind, men triagekriterier, responsmål, godkendelser af sikkerhedsmeddelelser og lukningsevidens er inkonsistente. Løsningen er at integrere CVD med sårbarhedsstyring, hændelsesstyring og release-styring.

For det fjerde er leverandørevidens for overfladisk. Kritiske leverandører er kommercielt godkendt, men ikke vurderet for påvirkning af produktsikkerhed. Løsningen er leverandørklassificering efter produktrisiko og obligatorisk evidens for kritiske komponenter.

For det femte er post-market-overvågning reaktiv. Teams reagerer på hastende sårbarheder, men gennemfører ikke periodiske produktrisikogennemgange. Løsningen er planlagt post-market-sikkerhedsgennemgang knyttet til ledelsesrapportering.

For det sjette er revisionsbeviset for manuelt. Compliance-teams jagter screenshots. Løsningen er evidence by design, hvor engineering-systemer, ticketing-workflows og repositories anvendes som autoritative kilder.

Opbyg evidensfilen, før fristen opbygger den for jer

Cyber Resilience Act belønner organisationer, der kan dokumentere produktsikkerhed som en operationel disciplin. Den skaber risiko for organisationer, der behandler evidens som en complianceøvelse i sidste øjeblik.

Start med ét produkt. Opbyg én produktsikkerhedsfil. Kortlæg den til ISO/IEC 27001:2022 og ISO/IEC 27002:2022. Vedhæft evidens for sikker udvikling, SBOM, CVD-registreringer, leverandørdokumentation og post-market-overvågning. Gennemfør en auditsimulering, før en ekstern part gør det for jer.

Clarysec kan hjælpe jer med at accelerere rejsen med Zenith Blueprint, Zenith Controls, Enterprise Secure development policy, Vulnerability management policy, Asset management policy, Third-party and supplier security policy, Logging and monitoring policy og Information Security Incident Management Policy.

Jeres vigtigste CRA 2026-spørgsmål er ikke: “Har vi sikkerhedskontroller?”

Det er: “Kan vi dokumentere produktsikkerhed, release for release, komponent for komponent, sårbarhed for sårbarhed, efter at produktet allerede er på markedet?”

Opbyg evidensfilen nu, forbind den med jeres ISMS, og gør hver fremtidig produktrelease revisionsklar by design.