CRA 2026: produktsäkerhetsakt med ISO 27001

En tillverkare av uppkopplade enheter kallar in sin CISO, Maria, till ett möte en fredagseftermiddag. Försäljningsorganisationen har precis säkrat ett europeiskt distributionsavtal. Juridikfunktionen frågar om företaget kan stödja överensstämmelse med Cyber Resilience Act. Utvecklingsorganisationen säger att säker utveckling är ”i stort sett täckt” eftersom kodgranskning, SAST och patchning finns på plats. Inköpsfunktionen säger att leverantörerna ”omfattas av sekretessavtal”. Produktteamen har firmwareberoenden i ett verktyg, inventarier över moln-API:er i ett annat och sårbarhetsärenden i Jira. Regelefterlevnadsfunktionen har certifieringsunderlag för ISO/IEC 27001:2022, men det är strukturerat kring organisationens ISMS, inte kring varje produkt som släpps ut på EU-marknaden.

Sedan kommer den obekväma frågan: ”Om en EU-myndighet, kund, anmält organ eller större distributör begär produktsäkerhetsakten 2026, kan vi ta fram den inom en vecka?”

För många programvaruleverantörer, tillverkare av smarta enheter och leverantörer av uppkopplade tjänster är det ärliga svaret nej. Inte för att de saknar säkerhetskontroller, utan för att deras produktsäkerhetsunderlag är utspritt. Poster om säker utveckling ligger hos utvecklingsorganisationen. SBOM:er genereras per bygge men omfattas inte av styrning. Samordnad sårbarhetsrapportering finns som webbsida, men är inte alltid kopplad till triagering, korrigeringar, säkerhetsmeddelanden och eftermarknadsövervakning. Leverantörssäkerhet ligger begravd i inköpsavtal. Incidentrapportering tillhör säkerhetsdriften, medan dokumentation för överensstämmelse tillhör produktregelefterlevnad.

EU:s Cyber Resilience Act förändrar verksamhetsmodellen. Produkters cybersäkerhet är inte längre endast bästa praxis eller ett avtalsmässigt löfte. Den blir en livscykelbaserad skyldighet att kunna visa underlag. Organisationer måste kunna visa hur cybersäkerhetskrav byggs in i design, utveckling, lansering, sårbarhetshantering, uppdateringar och övervakning efter att produkten har släppts ut på marknaden.

Det är här ISO/IEC 27001:2022 blir kraftfullt, om det används rätt. Det är inte i sig ett produktcertifieringssystem, men dess ISMS samt kontroller för risk, tillgångar, leverantörer, säker utveckling, sårbarheter och incidenter kan utgöra ryggraden i en CRA-produktsäkerhetsakt. Målet är inte att skapa ytterligare en efterlevnadssilo. Målet är att omvandla ert befintliga ISMS till ett underlagssystem på produktnivå.

Som Clarysecs Zenith Blueprint: en revisors 30-stegs färdplan uttrycker det i fas 2, steg 8, underlagsarkitektur:

”Underlag ska inte samlas in i slutet av revisionscykeln. Det ska byggas in i kontrollen, tilldelas en ägare, tidsstämplas av processen och kunna återanvändas för varje krav som ställer samma fråga med olika formulering.”

Den meningen fångar kärnan i CRA-beredskap. Frågan är inte bara: ”Har vi säker utveckling?” Frågan är: ”Kan vi bevisa säker utveckling, komponentkännedom, sårbarhetshantering och eftermarknadsövervakning för denna produkt, denna version, denna release och denna marknad?”

CRA-produktsäkerhetsakten är ett levande underlagssystem

En CRA-produktsäkerhetsakt ska inte behandlas som en statisk PDF som tas fram en gång före lansering och därefter glöms bort. Den ska vara en strukturerad dokumentation som beskriver produktens säkerhetshistorik från idé till avslutat stöd.

En användbar akt förklarar:

1. Vad produkten är och hur den är avsedd att användas.
2. Vilken programvara, firmware, molntjänster och tredjepartsberoenden den innehåller.
3. Vilka cybersäkerhetsrisker som har bedömts.
4. Vilka säkerhetskrav som har tillämpats.
5. Hur säker utveckling har genomförts.
6. Hur sårbarheter tas emot, triageras, åtgärdas och rapporteras.
7. Hur säkra uppdateringar levereras.
8. Hur leverantörer och komponenter med öppen källkod kontrolleras.
9. Hur incidenter och aktivt utnyttjade sårbarheter eskaleras.
10. Hur produkten övervakas efter att den har släppts ut på marknaden.

För en CISO är detta en utmaning kopplad till ISMS-underlag. För en ansvarig för produktregelefterlevnad är det teknisk dokumentation. För utvecklingsorganisationen är det DevSecOps och release-styrning. För ledningen handlar det om marknadstillträde och ansvarskontroll.

Misstaget är att behandla dessa som separata arbetsflöden. En bättre modell är att bygga en underlagsakt på produktnivå som mappas mot kontroller i ISO/IEC 27001:2022 och ISO/IEC 27002:2022, och därefter korsmappa samma underlag mot NIS2, DORA, GDPR, NIST och COBIT 2019 där det är relevant.

Clarysecs Zenith Controls: vägledning för korsvis efterlevnad beskriver detta som en kedja från kontroll till underlag och vidare till revisor:

”En underlagsakt för korsvis efterlevnad ska mappa varje skyldighet till den operativa kontrollen, det återkommande underlagsobjektet, den ansvariga ägaren och det revisionsperspektiv som kommer att användas för att pröva den.”

Det är den disciplin som CRA-förberedelser kräver. Produktsäkerhetsakten är inte bara en mapp. Den är översättningslagret mellan produktutveckling, säkerhetsstyrning, bedömning av överensstämmelse och kundförsäkran.

Bygg först produktens underlagsryggrad

Akten behöver en konsekvent struktur innan team börjar ladda upp poster. Utan en tydlig ryggrad blir underlaget en hög av skärmdumpar, exporter och policy-PDF:er som ingen revisor kan följa.

För workshoppar om CRA-beredskap rekommenderar Clarysec normalt följande struktur för produktsäkerhetsakten i organisationer som redan driver ett ISO/IEC 27001:2022-ISMS.

Denna tabell ersätter inte rättsliga skyldigheter avseende teknisk dokumentation. Den ger verksamheten en operativ modell för att visa dem.

I Zenith Blueprint fokuserar fas 1, steg 3 på definition av omfattning och gränser. För CRA blir detta steg produktspecifikt. Definiera produktfamilj, programvaruversioner, driftsättningsantaganden, användarroller, anslutna tjänster, uppdateringskanaler och stödperiod. Om ISMS-omfattningen är ”organisationens SaaS- och enhetshanteringsplattform” måste CRA-akten ändå besvara en snävare fråga: ”Vilken produkt med digitala element släpps ut på EU-marknaden, och vad ingår i den produkten?”

Mappa säker utveckling till poster på produktnivå

Kärnan i produktsäkerhetsakten är underlag för säkerhet genom design. ISO/IEC 27001:2022 tillhandahåller styrningssystemet. ISO/IEC 27002:2022 ger vägledning för genomförande genom kontroller som A.8.25 Säker utvecklingslivscykel, A.8.27 Säker systemarkitektur och tekniska principer, A.8.28 Säker kodning och A.8.29 Säkerhetstestning vid utveckling och acceptans.

Den viktiga förflyttningen är från generella påståenden om säker utveckling till release-specifika poster. ”Vi utför kodgranskning” räcker inte. Akten ska visa vilken release som granskades, vilka risker som beaktades, vilka säkerhetstester som godkändes, vilka sårbarheter som accepterades eller åtgärdades och vem som godkände releasen.

Clarysecs Enterprise Policy för säker utveckling är utformad för att framtvinga detta revisionsspår. I klausul 6.1, krav för säker utvecklingslivscykel, anges:

”Varje release av produkt eller tjänst ska upprätthålla dokumenterat underlag för säkerhetskrav, designgranskning, aktiviteter för säker kodning, säkerhetstestning, beslut om åtgärdande av sårbarheter och release-godkännande före driftsättning i produktion.”

Denna klausul är användbar för CRA eftersom den gör säker utveckling till ett återkommande underlagsmönster. En revisor behöver inte dra slutsatsen att säker utveckling har skett. Revisorn kan granska release-posten.

För en smart termostat, medicinteknisk IoT-enhet, industriell sensor eller SaaS-ansluten produkt bör underlaget för säker utveckling omfatta:

• Produktsäkerhetskrav mappade mot identifierade risker.
• Hotmodell eller analys av missbruksfall för produkten och anslutna tjänster.
• Arkitekturgranskning, inklusive tillitsgränser och externa gränssnitt.
• Standard för säker kodning och bevis på utvecklares bekräftelse eller utbildning.
• SAST, DAST, analys av programvarusammansättning, skanning efter hemligheter och firmwareanalys där det är tillämpligt.
• Åtgärdsärenden för högriskfynd.
• Poster för riskacceptans med verksamhets- och säkerhetsgodkännande.
• Checklista för releasebeslutspunkt som visar att säkerhetskriterierna uppfylldes.
• Underlag för kryptografisk signering och uppdateringsintegritet.
• Antaganden om stödperiod och livscykelns slut.

Andra standarder stärker metoden. ISO/IEC 27005 stödjer riskansatsen bakom dessa poster. ISO/IEC 27017 är användbar när molntjänster ingår i produktens ekosystem. ISO/IEC 27035 stödjer incidenthantering. ISO/IEC 29147 och ISO/IEC 30111 är särskilt relevanta för sårbarhetsrapportering och sårbarhetshantering. ISO/IEC 27036 stödjer leverantörssäkerhet, vilket är viktigt när produkten innehåller outsourcad programvara, inbäddade moduler, hanterade molntjänster eller tredjepartsbibliotek.

I Zenith Controls mappas CRA-underlag för säker utveckling normalt kring kontrollteman i ISO/IEC 27002:2022, såsom informationssäkerhet i projektledning, säker utvecklingslivscykel, säker kodning, säkerhetstestning, ändringshantering och hantering av tekniska sårbarheter. Vägledningen kopplar också dessa till tillgångsförteckning och leverantörskontroller, eftersom ingen process för säker utveckling är fullständig om organisationen inte kan identifiera de komponenter den levererar.

Behandla SBOM som reglerat produktunderlag

Software Bill of Materials behandlas ofta som en teknisk artefakt. För CRA-beredskap ska den behandlas som produktunderlag.

En användbar SBOM visar vilka komponenter som ingår i produkten, vilka versioner som används, var de kommer ifrån, vilka licenser som gäller, vilka sårbarheter som påverkar dem och vilka releaser som innehåller dem. För firmware och inbäddade produkter kan detta omfatta operativsystempaket, bootloaders, bibliotek, drivrutiner, containrar, tredjepartsmoduler och molnberoenden som krävs för produktens drift.

Problemet är att många organisationer genererar SBOM:er men inte styr dem. En byggpipeline kan producera en SPDX- eller CycloneDX-fil, men ingen validerar fullständigheten. Säkerhetsverktyg kan flagga sårbarheter, men resultaten kopplas inte till produktversioner. Inköpsfunktionen kan godkänna en leverantör, men leverantörens komponentlista stäms inte av mot den lanserade produkten.

Clarysecs Enterprise Policy för tillgångshantering hanterar denna styrningslucka i klausul 5.2, förteckning över information och relaterade tillgångar:

”Informationstillgångar och relaterade teknikkomponenter ska identifieras, tilldelas en ägare, klassificeras där det är tillämpligt och underhållas i en förteckning som stödjer riskbedömning, hantering av sårbarheter, ändringsstyrning och revisionsbevis.”

För CRA blir den klausulen produktspecifik. SBOM är en del av förteckningen över relaterade teknikkomponenter. Den behöver en ägare, en bevaranderegel, en valideringsprocess och en koppling till sårbarhetshantering.

En praktisk regel för SBOM-underlag är enkel: varje lanserad produktversion måste ha en godkänd komponentförteckning som kan matchas mot release-artefakten. Om organisationen inte kan koppla SBOM till exakt firmwareavbildning, applikationspaket, container-digest eller SaaS-release är SBOM ett svagt underlag.

Om fler än två rader underkänns är problemet normalt inte SBOM-verktyget. Det är styrningen. Produktsäkerhetsakten bör registrera en korrigerande åtgärd i ISMS, eftersom svagheter i CRA-underlag också är ett problem med kontrolleffektivitet enligt ISO/IEC 27001:2022.

Koppla CVD till sårbarhetshantering och release-styrning

Samordnad sårbarhetsrapportering är ett av de mest synliga områdena för CRA-beredskap eftersom externa forskare, kunder och myndigheter kan testa det direkt. Att publicera en sida för sårbarhetsrapportering eller en security.txt-fil är användbart, men det är bara ingången. Produktsäkerhetsakten måste visa att de bakomliggande processerna fungerar.

En försvarbar uppsättning underlag för CVD och sårbarhetshantering bör omfatta:

• Publik rapporteringskanal och instruktioner för inlämning.
• Process för bekräftelse till forskare.
• Triageringskriterier, inklusive bedömning av allvarlighetsgrad och exploaterbarhet.
• Analys av produktpåverkan.
• Ägarskap för åtgärdande och målfrister.
• Mallar för kundmeddelanden och uppdateringskommunikation.
• Underlag för säker patchutveckling och testning.
• Poster om samordnad publicering där det är tillämpligt.
• Erfarenhetsåterföring och återkommande trendanalys av sårbarheter.

Clarysecs Enterprise Policy för sårbarhets- och patchhantering, klausul 6.3, mottagning, triagering och åtgärdande av sårbarheter, anger:

”Rapporterade sårbarheter ska loggas, bedömas avseende påverkade tillgångar och produkter, prioriteras enligt risk och exploaterbarhet, tilldelas en ansvarig ägare och följas upp genom åtgärdande, verifiering, kommunikation och stängning.”

Den klausulen kopplar CVD till SBOM, tillgångsförteckning, utvecklingsärenden, release-hantering och eftermarknadsövervakning. Det är också den klausul som revisorer naturligt kommer att testa: visa mottagningsposten, visa de påverkade produkterna, visa triageringen, visa korrigeringen, visa kundkommunikationen, visa stängningen.

Er befintliga Policy för incidenthantering bör också utökas till att omfatta produktsårbarheter som blir incidenter eller kräver extern avisering. ISO/IEC 27002:2022 A.5.24 omfattar planering och förberedelse för incidenthantering, A.5.25 omfattar bedömning och beslut om informationssäkerhetshändelser, A.5.26 omfattar respons på informationssäkerhetsincidenter och A.5.27 omfattar lärande från incidenter.

I Zenith Controls behandlas sårbarhetshantering både som förebyggande och korrigerande. Den förebyggande sidan omfattar förteckning, säker utveckling, leverantörsövervakning och säker konfiguration. Den korrigerande sidan omfattar detektering, triagering, patchning, kommunikation och incidenteskalering. Denna åtskillnad är viktig eftersom sårbarhetshantering efter utsläppande på marknaden är en del av produktens livscykelskyldighet, inte en efterhandsåtgärd.

Leverantörsunderlag är den dolda svagheten

Produktsäkerhetsakten kommer ofta att prövas hårdast där tillverkaren förlitar sig på andra. Det gäller inbäddade moduler, outsourcad firmwareutveckling, white label-komponenter, molndrift, mobila SDK:er, betaltjänster, kryptografiska bibliotek och hanterade supportleverantörer.

Det vanliga felmönstret är avtalsmässig abstraktion. Tillverkaren säger: ”Vår leverantör ansvarar för det.” Vid granskning av produktsäkerhet räcker det inte. Organisationen måste visa att leverantörsrisker identifieras, säkerhetskrav kommuniceras, underlag samlas in, sårbarheter samordnas och ändringar kontrolleras.

Clarysecs Enterprise Policy för leverantörssäkerhet och tredjepartssäkerhet, klausul 7.1, säkerhetskrav för leverantörer, anger:

”Leverantörer som utvecklar, driver, behandlar, stödjer eller väsentligt påverkar informationssystem, produkter eller tjänster ska bedömas utifrån risk och omfattas av säkerhetskrav som täcker åtkomst, hantering av sårbarheter, incidentavisering, underleverantörer, kontinuitet och tillhandahållande av underlag.”

För CRA är formuleringen ”väsentligt påverkar produkter” central. Om en leverantörskomponent kan införa en sårbarhet, störa uppdateringar, exponera kunddata eller kompromettera enhetens integritet hör den hemma i produktsäkerhetsakten.

Samma policy kan också stödja avtal om SBOM. Klausul 7.3 anger:

”För alla tredjepartsprogramvarukomponenter, bibliotek eller operativsystem som ska integreras i företagets produkter med digitala element ska leverantören på begäran tillhandahålla en maskinläsbar Software Bill of Materials (SBOM) i ett standardformat såsom SPDX eller CycloneDX. Detta krav ska införas i alla inköps- och leverantörsavtal.”

Ett starkt leverantörsunderlag bör omfatta leverantörsklassificering utifrån produktpåverkan, säkerhetskrav i avtal, leverantörens underlag för säker utveckling av kritiska komponenter, leverantörsåtaganden för sårbarhetsrapportering, SBOM eller komponentdeklarationer där det är möjligt, patchstöd och tidslinjer för livscykelns slut, periodiska granskningsposter och eskaleringsvägar för sårbarheter som har sitt ursprung hos leverantören.

ISO/IEC 27002:2022 A.5.19, A.5.20 och A.5.21 ger de centrala kontrolltemana för leverantörer. ISO/IEC 27036 ger ytterligare djup för säkerhet i leverantörsrelationer. I termer av korsvis efterlevnad betonar NIS2 leveranskedjan och sårbarhetshantering. DORA betonar IKT-tredjepartsrisk för finansiella entiteter. GDPR blir relevant när produkten eller dess molntjänster behandlar personuppgifter. COBIT 2019 ramar in leverantörsstyrning som en fråga om styrning av företagsteknik, inte enbart som en fråga för säkerhetsdriften.

Eftermarknadsövervakning gör underlag till drift

De mest mogna produktsäkerhetsorganisationerna tänker längre än till lansering. De frågar: ”Hur vet vi om denna produkt har blivit riskfylld efter att den finns ute i fält?”

Eftermarknadsövervakning bör fånga signaler från sårbarhetsflöden, exploateringsinformation, kundsupport, telemetri, bug bounty- eller forskarrapporter, leverantörsaviseringar, molnloggar, incidentposter och fältprestandadata. Den bör också omfatta periodisk granskning av produktrisk när hotläget förändras.

Clarysecs Enterprise Loggnings- och övervakningspolicy, klausul 5.4, säkerhetsövervakning och granskning, anger:

”Säkerhetsrelevanta händelser ska samlas in, granskas, eskaleras och bevaras på ett sätt som stödjer snabb detektering, utredning, incidentrespons, rapportering av regelefterlevnad och ständig förbättring.”

För uppkopplade produkter måste detta tolkas med omsorg. Övervakning måste respektera integritet, dataminimering och rättsliga begränsningar, särskilt när telemetri omfattar personuppgifter eller kunders operativa data. GDPR-mappning är viktig. Produktsäkerhetsteam bör arbeta tillsammans med integritetsteam för att definiera vilken telemetri som är nödvändig för säkerhet, hur den minimeras, hur länge den bevaras och hur kunder informeras.

Underlag för eftermarknadsövervakning bör omfatta en plan för produktsäkerhetsövervakning, källor för sårbarhetsinformation, mottagningskanaler för kundrapporter, aviseringskanaler från leverantörer, omfattning för telemetri- eller logggranskning, protokoll från periodiska produktriskgranskningar, uppföljning av patchanvändning, analys av incidenttrender och indata till ledningens genomgång.

I Zenith Blueprint fokuserar fas 5, steg 30 på ständig förbättring och beredskap för uppföljande granskning. För CRA är det här produktsäkerhetsakten blir en levande akt. Varje produktrelease, sårbarhet, leverantörsändring och fältsignal bör uppdatera underlagsposten.

En underlagsakt, många efterlevnadsfrågor

En väl utformad CRA-produktsäkerhetsakt minskar dubbelarbete eftersom samma underlag besvarar flera efterlevnadsfrågor. Språket ändras, men kontrollverkligheten är ofta likartad.

Zenith Controls är utformat för denna återanvändning. Det mappar kontrollteman i ISO/IEC 27002:2022 till attribut som förebyggande, upptäckande och korrigerande kontrollsyfte, cybersäkerhetskoncept, operativa förmågor och säkerhetsegenskaper. För CRA hjälper detta en CISO att förklara varför ett enskilt underlagsobjekt, exempelvis en säkerhetsgranskning av en release, stödjer säker utveckling, riskbehandling, ändringsstyrning, sårbarhetshantering och revisionsberedskap.

Förbered för olika revisionsperspektiv

En CRA-produktsäkerhetsakt kan prövas av en ISO-revisor, internrevisionsteam, team för kundförsäkran, granskare av produktöverensstämmelse, tillsynsmyndighet, NIST-baserad bedömare eller ISACA-utbildad COBIT-revisor. Alla ställer liknande frågor genom olika perspektiv.

Samma svaga punkt kommer att exponeras på olika sätt. Om SBOM:er genereras men inte bevaras ser ISO-revisorn ett problem med registerstyrning och operativa kontroller. NIST-bedömaren ser en svaghet i tillgångs- och sårbarhetshantering. COBIT-revisorn ser svag styrning av informationstillgångar. Produktgranskaren ser otillräcklig teknisk dokumentation.

En 30-stegs färdplan anpassad för CRA-beredskap

Zenith Blueprint hindrar regelefterlevnadsteam från att gå direkt till dokumentinsamling. För CRA blir 30-stegs färdplanen ett program för produktsäkerhetsunderlag.

Fas 1 börjar med mappning av skyldigheter och omfattning. Identifiera vilka produkter, versioner, komponenter, molntjänster och stödprocesser som omfattas. Bekräfta avsedd användning, användarkategorier, marknader och period för säkerhetsstöd.

Fas 2 bygger underlagsarkitekturen. Definiera index för produktsäkerhetsakten, underlagsägare, bevarandekrav, arkivstruktur och godkännandearbetsflöde. Anpassa till utvecklingssystem i stället för att tvinga fram manuella uppladdningar.

Fas 3 genomför operativa kontroller. Säker utveckling, SBOM-generering, sårbarhetshantering, leverantörsunderlag, releasebeslutspunkter, säkra uppdateringar och incidenteskalering måste fungera som verkliga processer.

Fas 4 testar revisionsberedskap. Välj en produktrelease och genomför en simulerad revision. Kan teamet hämta SBOM? Kan de bevisa säkerhetstestning? Kan de visa hur en sårbarhet triagerades? Kan de koppla leverantörsunderlag till produktkomponenter?

Fas 5 bäddar in övervakning och förbättring. Eftermarknadsövervakning, trendanalys av sårbarheter, leverantörsgranskningar och indata till ledningens genomgång håller akten aktuell.

Denna sprint visar normalt sanningen snabbt. Organisationer misslyckas sällan för att de saknar alla kontroller. De misslyckas för att kontrollerna inte är sammanlänkade på produktnivå.

Vanliga luckor i CRA-beredskap före 2026

Hos programvaruleverantörer, enhetstillverkare och leverantörer av uppkopplade tjänster återkommer samma typer av luckor.

För det första är ISMS-omfattningen för organisationsövergripande. Den täcker organisationen, men inte tillräckligt med detaljer om produktens livscykel. Åtgärden är att skapa bilagor och underlagsakter på produktnivå.

För det andra finns SBOM:er men de är inte tillförlitliga. De genereras av verktyg men granskas, godkänns, bevaras eller kopplas inte till sårbarhetsbeslut. Åtgärden är SBOM-styrning, inte enbart SBOM-produktion.

För det tredje är CVD publik men inte operativt mogen. Rapporter kommer in, men triageringskriterier, svarsmål, godkännande av säkerhetsmeddelanden och underlag för stängning är inkonsekventa. Åtgärden är att integrera CVD med sårbarhetshantering, incidenthantering och release-hantering.

För det fjärde är leverantörsunderlaget för ytligt. Kritiska leverantörer godkänns kommersiellt men bedöms inte utifrån påverkan på produktsäkerhet. Åtgärden är leverantörsklassificering utifrån produktrisk och obligatoriskt underlag för kritiska komponenter.

För det femte är eftermarknadsövervakningen reaktiv. Team svarar på akuta sårbarheter men genomför inte periodiska produktriskgranskningar. Åtgärden är schemalagd säkerhetsgranskning efter utsläppande på marknaden kopplad till ledningsrapportering.

För det sjätte är revisionsunderlaget alltför manuellt. Regelefterlevnadsteam jagar skärmdumpar. Åtgärden är underlag genom design, där utvecklingssystem, ärendearbetsflöden och lagringsplatser används som auktoritativa källor.

Bygg underlagsakten innan tidsfristen bygger den åt dig

Cyber Resilience Act premierar organisationer som kan visa produktsäkerhet som en operativ disciplin. Den skapar risk för organisationer som behandlar underlag som en sista minuten-övning i efterlevnad.

Börja med en produkt. Bygg en produktsäkerhetsakt. Mappa den mot ISO/IEC 27001:2022 och ISO/IEC 27002:2022. Bifoga underlag för säker utveckling, SBOM, CVD-poster, leverantörssäkring och eftermarknadsövervakning. Genomför en revisionssimulering innan någon extern gör det åt er.

Clarysec kan hjälpa er att accelerera resan med Zenith Blueprint, Zenith Controls, Enterprise Policy för säker utveckling, Policy för sårbarhets- och patchhantering, Policy för tillgångshantering, Policy för leverantörssäkerhet och tredjepartssäkerhet, Loggnings- och övervakningspolicy och Policy för incidenthantering.

Er viktigaste CRA 2026-fråga är inte: ”Har vi säkerhetskontroller?”

Den är: ”Kan vi bevisa produktsäkerhet, release för release, komponent för komponent, sårbarhet för sårbarhet, efter att produkten redan finns på marknaden?”

Bygg underlagsakten nu, koppla den till ert ISMS och gör varje framtida produktrelease revisionsklar genom design.