CRA kontra ISO 27001: de efterlevnadsluckor ditt ISMS inte täcker

ISO 27001 täcker inte CRA. Den här guiden visar exakt var ditt ISMS hjälper, var det brister och vad du behöver lägga till före 2027.

CRA Evidence Team Publicerad 12 januari 2026 Uppdaterad 16 maj 2026
Jämförelse mellan CRA och ISO 27001 som visar luckor på produktnivå
I denna artikel

Om ditt företag är ISO 27001-certifierat kanske du antar att du är väl positionerad för Cyber Resilience Act (CRA). Det är du inte. Inte utan betydande tilläggsarbete.

ISO 27001 skyddar din organisations informationstillgångar. Cyber Resilience Act (Förordning (EU) 2024/2847) kräver att varje produkt med digitala element som du släpper på EU-marknaden är säker by design, levereras med en software bill of materials (SBOM) och får säkerhetsuppdateringar under sin förväntade livstid. Det rör sig om skyldigheter på produktnivå, inte organisatoriska. Bristande efterlevnad kan ge böter på upp till 15 miljoner euro eller 2,5 procent av global årlig omsättning (Artikel 64). Se guiden om CRA-böter.

Rapporteringsskyldigheterna enligt Artikel 14 börjar gälla den 11 september 2026. Full efterlevnad krävs senast den 11 december 2027. Se den fullständiga CRA-implementeringstidslinjen.

Den här guiden om ISO 27001 kontra CRA kartlägger exakt var ditt ISMS hjälper, var det brister och vad du behöver lägga till.

Sammanfattning

  • ISO 27001 = organisatorisk säkerhetshantering
  • CRA = produktkrav på cybersäkerhet (Bilaga I, Förordning (EU) 2024/2847)
  • ISO 27001 innebär INTE CRA-efterlevnad
  • ISO 27001 ger en grund för processer för säker utveckling
  • CRA kräver produktspecifik evidens: SBOM, sårbarhetshantering, CE-märkning
  • Båda tillsammans ger en stark övergripande säkerhetsposition
15 miljoner EUR
Högsta bötesbelopp
eller 2,5 procent av global årlig omsättning
11 sep 2026
Rapportering enligt Artikel 14
sårbarhetsskyldigheter börjar
11 dec 2027
Full tillämpning av CRA
bedömning av överensstämmelse krävs
5 år
Minsta stödperiod
eller förväntad produktlivstid (Artikel 13.8)

Källa: Förordning (EU) 2024/2847, Artikel 13, 14 och 64.

Vad täcker ISO 27001 jämfört med vad CRA kräver?

Vad ISO 27001 täcker

ISO 27001 är en standard för ledningssystem för informationssäkerhet (ISMS) med kontroller på organisationsnivå.

Kontroller på organisationsnivå
  • Informationssäkerhetspolicyer
  • Tillgångshantering
  • Åtkomstkontroll till system och data
  • Användning av kryptografi
  • Fysisk, operativ och kommunikationssäkerhet
  • Leverantörsrelationer
  • Incidenthantering
  • Verksamhetskontinuitet
  • Efterlevnadshantering

Fokus: skydda organisationens informationstillgångar.

Vad CRA täcker

CRA är en produktförordning med cybersäkerhetskrav för produkter med digitala element (Bilaga I).

Krav på produktnivå
  • Säkerhet by design i produkter
  • Inga kända exploaterbara sårbarheter
  • Säker standardkonfiguration
  • Skydd mot obehörig åtkomst i produkten
  • Produktens dataskydd och uppdateringsförmåga
  • Sårbarhetshantering och ENISA-rapportering
  • SBOM för produktkomponenter (Artikel 13.5)
  • Policy för samordnad sårbarhetsredovisning (Artikel 13.6)
  • Offentlig sårbarhetskontakt (Artikel 13.7)
  • CE-märkning och bedömning av överensstämmelse

Fokus: säkerställa att produkter du säljer är säkra.

CRA klassificerar produkter i kategorier: standard, Important Class I, Important Class II och Critical (Bilaga III och IV). Varje kategori medför olika krav på bedömning av överensstämmelse. En Important Class II-produkt kräver obligatorisk tredjepartsbedömning av ett anmält organ, oavsett din ISO 27001-certifieringsstatus. Se guiden om CRA-produktklassificering.

Den grundläggande skillnaden

Diagram över ISO 27001 kontra CRA: säkerhetstäckning per lager med tre staplade lager: organisationssäkerhet täckt av ISO 27001, delade utvecklingsprocesser och produktsäkerhet som krävs av CRA

Där ISO 27001 hjälper CRA och där det brister

Där ISO 27001 hjälper CRA

CRA-krav ISO 27001-stöd Hur det hjälper
Säker utveckling A.8.25-28 (Säker utveckling) Processfundament
Sårbarhetshantering A.8.8 (Tekniska sårbarheter) Organisatorisk process
Incidenthantering A.5.24-26 (Incidenthantering) Responsförmåga
Leverantörsstyrning A.5.19-22 (Leverantörsrelationer) Leveranskedjans säkerhet
Åtkomstkontroll A.5.15-18, A.8.2-5 Säkerhet i utvecklingsmiljön
Kryptografi A.8.24 (Kryptografi) Kryptopolicygrund
Dokumentation A.5.1 (Policyer), 7.5 (Dokumenterad info) Dokumentationskultur
Riskbedömning 6.1 (Riskbedömning) Riskmetodik

Där ISO 27001 brister

CRA-krav ISO 27001-brist Vad som saknas
SBOM Delvis: A.8.26/A.8.28 täcker komponentkännedom, inte maskinläsbart SBOM-format Standardiserat SBOM (SPDX/CycloneDX) per Artikel 13.5
CE-märkning Täcks inte Process för bedömning av överensstämmelse
Produktsäkerhetstestning Begränsad Produktspecifik testevidens för teknisk dokumentation
Säker som standard Inte produktfokuserad Produktkonfigurationskrav
Stödperiod Täcks inte Minst 5 år, eller förväntad produktlivstid om kortare (Artikel 13.8)
ENISA-rapportering Täcks inte Tidig varning inom 24 timmar, initial notifiering inom 72 timmar och slutrapport till nationellt CSIRT via den gemensamma rapporteringsplattformen (Artikel 14)
CVD-policy Täcks inte Dokumenterad policy för samordnad sårbarhetsredovisning (Artikel 13.6)
Offentlig sårbarhetskontakt Täcks inte Enda kontaktpunkt för sårbarhetrapporter, till exempel security.txt (Artikel 13.7)
Användardokumentation Begränsad Produktens säkerhetsinstruktioner
Teknisk dokumentation Täcks inte CRA-dokumentationsformat per Bilaga VII

Sammanfattning av gapanalys

Stark grund (ISO 27001 hjälper avsevärt):

  • Säkerhetskultur och medvetenhet
  • Riskhanteringsmetodik
  • Incidentresponsförmåga
  • Leverantörssäkerhetshantering
  • Policyer för säker utvecklingslivscykel
  • Ramverk för åtkomstkontroll
  • Dokumentationspraxis

Delvis täckning (ISO 27001 hjälper men räcker inte):

  • Sårbarhetshantering (organisatoriskt omfång kontra produktomfång)
  • Kryptografi (policy kontra produktimplementering)
  • Säkerhetstestning (företagssystem kontra produkttestning)
  • Ändringshantering (IT-ändring kontra produktmodifikation)
  • SBOM (komponentkännedom i A.8.26/A.8.28 kontra maskinläsbart SBOM-format)

Luckor (CRA-specifika, täcks inte av ISO 27001):

  • SBOM-generering och underhåll i standardiserat format
  • Bedömning av produktens överensstämmelse
  • CE-märkningsprocess
  • Sårbarhetsrapportering till nationellt CSIRT via den gemensamma rapporteringsplattformen (Artikel 14)
  • Produktspecifik teknisk dokumentation (Bilaga VII)
  • Åtagande om stödperiod (Artikel 13.8)
  • Verifiering av säker standardkonfiguration
  • Krav på produktuppdateringsmekanism
  • Policy för samordnad sårbarhetsredovisning (Artikel 13.6)
  • Offentlig kontakt för sårbarhetsrapportering (Artikel 13.7)

Hur du bygger på ISO 27001 för CRA

Använd ditt ISMS som grund

Om du är ISO 27001-certifierad har du en stark grund att bygga vidare på. Nyckeln är att utöka befintliga processer mot produktskyldigheter i stället för att börja från grunden.

Utöka befintliga processer:

ISO 27001-process CRA-utökning
Riskbedömning (6.1) Produktriskbedömning
Sårbarhetshantering (A.8.8) Produktsårbarhetshantering och CSIRT-rapportering
Leverantörsstyrning (A.5.19-22) SBOM-insamling från leverantörer
Incidenthantering (A.5.24-26) CSIRT-rapportering per Artikel 14
Säker utveckling (A.8.25-28) Produktsäkerhetstestning och teknisk dokumentation

Nya processer att lägga till:

Ny process Syfte
SBOM-generering Komponentspårning per Artikel 13.5
Bedömning av överensstämmelse CE-märkning
Produktens tekniska dokumentation Regelverksdokumentation per Bilaga VII
Hantering av stödperiod Åtagande per Artikel 13.8
ENISA-rapporteringsprocedur Sårbarhetsnotifiering via nationellt CSIRT
CVD-policy Samordnad redovisning per Artikel 13.6

Praktiska integrationssteg

Steg 1: Utvidgning av omfång

  • Lägg till produktsäkerhet i ditt ISMS-omfång
  • Ta med produktutveckling i riskbedömningen
  • Utvidga tillgångsinventeringen till att inkludera produktkomponenter

Steg 2: Processuppdateringar

  • Uppdatera sårbarhetsproceduren för produktrapportering till nationellt CSIRT via den gemensamma rapporteringsplattformen
  • Lägg till SBOM i ändringshanteringen
  • Inkludera tidig varning inom 24 timmar, initial notifiering inom 72 timmar och slutrapport i din incidentresponsprocess

Steg 3: Dokumentationstillägg

  • Produktens tekniska dokumentation
  • SBOM-register
  • Evidens för bedömning av överensstämmelse
  • Dokumentation om stödperiod

Steg 4: Roller och ansvar

  • Tilldela ägarskap för produktsäkerhet
  • Definiera ansvar för CSIRT-rapportering
  • Etablera ägarskap för SBOM-underhåll
  • Tilldela ägarskap för CVD-policy

ISO 27001 Bilaga A-kontroller och CRA

De mest relevanta kontrollerna

Kontroll ISO 27001-roll CRA-användning
A.8.25 Säker utvecklingslivscykel

ISO 27001-rollPolicyer för säker utveckling.

CRA-användningGrund för produktens säkerhetskrav (Bilaga I, del I).

A.8.26 Applikationssäkerhetskrav

ISO 27001-rollSäkerhetskrav i utveckling.

CRA-användningBas för produktens väsentliga säkerhetskrav; delvis grund för SBOM-komponentinventering.

A.8.27 Säker systemarkitektur

ISO 27001-rollPrinciper för säker arkitektur.

CRA-användningProduktens säkerhetsarkitektur.

A.8.28 Säker kodning

ISO 27001-rollSäker kodningspraxis inklusive beroendespårning.

CRA-användningProduktkodens säkerhet; delvis grund för SBOM-komponentkännedom.

A.8.8 Hantering av tekniska sårbarheter

ISO 27001-rollOrganisatorisk sårbarhetshantering.

CRA-användningUtvidga till produktsårbarheter och rapportering till nationellt CSIRT via den gemensamma rapporteringsplattformen (Artikel 14).

A.5.19-22 Leverantörsrelationer

ISO 27001-rollLeverantörssäkerhetshantering.

CRA-användningSBOM-insamling från leverantörer och leveranskedjans säkerhet.

Räknas ISO 27001-certifiering för CRA-bedömning av överensstämmelse?

Täcker ISO 27001-certifiering CRA-efterlevnad?

Avgörande förståelse:

  • ISO 27001-certifiering visar organisatorisk säkerhetsmognad
  • CRA-efterlevnad är ett produktspecifikt lagkrav
  • ISO 27001 befriar dig inte från CRA
  • ISO 27001-revisorer bedömer inte CRA-efterlevnad

Rapporteringsskyldigheterna enligt Artikel 14 börjar den 11 september 2026. Full efterlevnad krävs senast den 11 december 2027. Bristande efterlevnad kan ge böter på upp till 15 miljoner euro eller 2,5 procent av global årlig omsättning (Artikel 64).

Revisionssynergier

ISO 27001-övervakningsrevision:

  • Årlig bedömning av ISMS
  • Kan inkludera produktsäkerhetsomfång
  • Evidens kan återanvändas för CRA

CRA-bedömning av överensstämmelse:

  • Produktspecifik utvärdering
  • Refererar till ISMS för processevidens
  • Kräver ytterligare produktevidens

Synergiområden:

  • Samordna revisionsschemata
  • Återanvänd evidens där det är tillämpligt
  • Integrerat ledningssystem
  • Gemensamt dokumentationsarkiv

Tre vanliga ISO 27001- och CRA-scenarier

Scenario 1 ISO 27001-certifierad, påbörjar CRA

Använd ISMS som processevidens. Behandla inte certifikatet som evidens för produktöverensstämmelse.

Använd från ISO 27001

Riskmetodik, leverantörsstyrning, incidentrespons och styrning av säker utveckling.

CRA-specifik evidens

Produktklassificering, SBOM-generering, Artikel 14-rapportering och teknisk dokumentation enligt Bilaga VII.

Beslutsregel: återanvänd ISMS-kontroller endast där de skapar evidens på produktnivå.

Scenario 2 Utan ISO 27001, påbörjar CRA

Prioritera förordningen med fast tidsfrist. Bygg ISO 27001-disciplin runt arbetet i stället för att försena produktarbetet.

Tidsfrister

Artikel 14-rapportering börjar den 11 september 2026. Full CRA-tillämpning börjar den 11 december 2027.

CRA först

Klassificering, SBOM, teknisk dokumentation, CVD-policy, offentlig kontakt och rapporteringsflöde.

Beslutsregel: börja med de regulatoriska produktplikterna och mogna sedan arbetssättet mot ISO 27001. Se CRA-guiden för startups.

Scenario 3 Flera produkter, centralt ISMS

Centralisera gemensamma kontroller, men håll överensstämmelseevidens separat för varje produktfamilj.

Centralisera

Riskmetod, sårbarhetshantering, leverantörskrav och utvecklingsstandarder.

Behåll per produkt

Teknisk dokumentation, SBOM, överensstämmelserutt, stödperiod och releaseevidens.

Beslutsregel: en gemensam produktsäkerhetsprocedur, ett evidensregister per produktfamilj.

Arbetsströmmar för integration från ISO 27001 till CRA

Produktomfång och klassificering

Mål

Avgöra vilka produkter som omfattas av CRA och vilken nivå som gäller.

Output

Klassificeringspost per produktfamilj.

Evidens

Motivering enligt Bilaga III/IV och överensstämmelserutt.

Riskmodell för produktsäkerhet

Mål

Utvidga ISMS-riskmetoden till missbruksfall och livscykelrisk för produkter.

Output

Produktriskbedömning.

Evidens

Mappning mot CRA Bilaga I-krav.

SBOM och leverantörsevidens

Mål

Göra komponentinsyn repeterbar för varje produktrelease.

Output

SBOM-process och krav för leverantörsintag.

Evidens

Artikel 13.5, A.5.19-22 och releasekopplade SBOM-poster.

Sårbarhetshantering och rapportering

Mål

Koppla ISO-sårbarhetshantering till CRA-produktrapportering.

Output

CVD-policy, offentlig kontakt och CSIRT-rapporteringsrunbook.

Evidens

Artikel 13.6/13.7, Artikel 14-ägarskap och rapporteringstider.

Teknisk dokumentation och överensstämmelserutt

Mål

Omvandla processmognad till produktspecifik överensstämmelseevidens.

Output

Teknisk dokumentation Bilaga VII, EU-försäkran om överensstämmelse och modulbeslut.

Evidens

Säkerhetsarkitektur, testrapporter, stödperiod och överensstämmelsebedömningspost.

Ägarskap och utbildning

Mål

Göra produktefterlevnad operativ, inte ett engångsprojekt.

Output

Namngivna ägare och teamutbildning.

Evidens

Ansvarstabell, utbildningsposter och intern revisionskadens.

Vanliga frågor

Befriar ISO 27001-certifiering ett företag från CRA-bedömning av överensstämmelse?

Nej. ISO 27001-certifiering visar organisatorisk mognad inom informationssäkerhet men utgör inte en CRA-bedömning av överensstämmelse. CRA kräver produktspecifik evidens: SBOM, teknisk dokumentation, EU-försäkran om överensstämmelse och, där det är tillämpligt, en bedömning av ett anmält organ. En revisor som bedömer ditt ISMS bedömer inte CRA-efterlevnad. Se CRA-vägar för bedömning av överensstämmelse.

Vilka ISO 27001 Bilaga A-kontroller är mest direkt relevanta för CRA Bilaga I?

Kontrollerna med störst överlapp är A.8.25-28 (säker utvecklingslivscykel), A.8.8 (hantering av tekniska sårbarheter) och A.5.19-22 (leverantörsrelationer). Dessa motsvarar CRA-krav på säkerhet by design, skyldigheten att hantera sårbarheter och bestämmelserna om SBOM och leveranskedjan. A.8.8 behöver utökas för att täcka rapportering av produktsårbarheter till nationellt CSIRT via ENISA:s gemensamma rapporteringsplattform (Artikel 14).

Kan evidens från ISO 27001-revision återanvändas i CRA:s tekniska dokumentation?

Ja, selektivt. Evidens från ditt ISMS som täcker säker utveckling (A.8.25-28), sårbarhetshantering (A.8.8) och leverantörskontroller (A.5.19-22) kan refereras i CRA:s tekniska dokumentation. Den tekniska dokumentationen kräver dock också produktspecifik evidens, inklusive säkerhetsarkitektur, testrapporter, SBOM och dokumentation om stödperiod, som ISO 27001-revisioner inte genererar.

Är ISO 27001:2022 bättre anpassad till CRA än ISO 27001:2013?

Ja. ISO 27001:2022 lade till kontroller som är mer relevanta för CRA, i synnerhet A.8.25-28 (säker utvecklingslivscykel, applikationssäkerhetskrav, säker arkitektur, säker kodning). 2013 års version hade svagare täckning inom dessa områden. Om du använder 2013 är det värt att köra en gapanalys mot 2022 års kontroller specifikt för CRA-syften.

Täcker ISO 27001 CRA:s SBOM-krav?

Delvis. A.8.26 (applikationssäkerhetskrav) och A.8.28 (säker kodning) inkluderar begrepp om komponentkännedom och beroendespårning. ISO 27001 kräver dock inte en maskinläsbar SBOM i CycloneDX- eller SPDX-format med NTIA:s minimumelement, vilket CRA Artikel 13.5 kräver. Organisatorisk medvetenhet är en grund, inte en ersättning.

Kan CRA-efterlevnadsarbete integreras i ett pågående ISO 27001-program?

Ja, och det är den rekommenderade ansatsen för redan certifierade företag. Utvidga ISMS-omfånget till att inkludera produktsäkerhet, lägg till produktspecifika procedurer för SBOM och CSIRT-rapportering, och referera till ISMS-evidens i din CRA-tekniska dokumentation. Nyckeln är att lägga till i stället för att duplicera: CRA-evidens tillhör den tekniska dokumentationen, inte ISMS-tillämplighetsförklaringen.

Nästa steg

Vad du bör göra under nästa kvartal

  1. Kör en gapanalys av dina ISMS Bilaga A-kontroller mot CRA Bilaga I. Börja med A.8.8, A.8.25-28 och A.5.19-22. Dessa bär det mesta av tyngden.
  2. Klassificera varje produkt enligt Bilaga III och IV. Vägen för bedömning av överensstämmelse beror på detta, inte på din ISO 27001-certifieringsstatus.
  3. Utvidga ditt ISMS-omfångsuttalande till att inkludera produktsäkerhet. Uppdatera tillämplighetsförklaringen så att produktskyldigheter är synliga för revisorer.
  4. Lägg till SBOM-generering (Artikel 13.5) i din ändringshanteringsprocess. CycloneDX eller SPDX, maskinläsbar, kopplad till varje release.
  5. Skapa eller uppdatera CSIRT-rapporteringsproceduren för Artikel 14: tidig varning inom 24 timmar, initial notifiering inom 72 timmar, slutrapport inom 14 dagar eller 1 månad beroende på incidenttyp. Se guiden om den gemensamma rapporteringsplattformen.
  6. Tilldela en produktsäkerhetsansvarig och en CVD-policyansvarig (Artikel 13.6 och 13.7). Dessa kan inte vara samma otydliga "säkerhetsteam"-plats.
  7. Schemalägg en kombinerad internrevision som täcker både ISO 27001-övervakning och beredskap för CRA:s tekniska dokumentation. Återanvänd evidens där det är tillämpligt.

Den här artikeln är endast i informationssyfte och utgör inte juridisk rådgivning. För specifik vägledning om efterlevnad, konsultera kvalificerat juridiskt ombud.

CRA Säkerhetsstandarder Efterlevnad
Share

Gäller CRA för din produkt?

Svara på 6 enkla frågor för att ta reda på om din produkt omfattas av EU:s Cyber Resilience Act. Få ditt resultat på under 2 minuter.

Redo att uppnå CRA-efterlevnad?

Börja hantera dina SBOM:ar och efterlevnadsdokumentation med CRA Evidence.