Säkerhetssupportperioder enligt EU:s CRA med ISO 27001

Klockan är 08:20 en tisdag och produktägaren för en uppkopplad B2B-gateway får ett meddelande från en reglerad kund: “Bekräfta säkerhetssupportperioden för firmwareversion 4.6, SLA för sårbarhetsrespons och om enheten fortsatt kommer att omfattas av säkerhetsuppdateringar under vårt femåriga tjänsteavtal.”

Klockan 09:00 har inköp vidarebefordrat ett DORA-frågeformulär för leverantörsgranskning. Klockan 10:15 frågar den juridiska funktionen om den marknadsförda supportperioden stämmer med kundavtalen. Klockan 11:00 dras informationssäkerhetschefen in i en NIS2-granskning av leverantörsrisk eftersom produkten används av en leverantör av hanterade tjänster i EU. Efter lunch frågar dataskyddsfunktionen om ett API-bibliotek utan support i produkten kan påverka säkerheten för personuppgifter enligt GDPR.

Den obekväma sanningen framkommer snabbt. Företaget har en färdplan, en patchprocess, en releasekalender och en kundsupportportal, men saknar styrt underlag för säkerhetssupportperioder.

Den luckan har betydelse. Enligt EU:s cyberresiliensförordning (CRA) är säkerhetssupportperioden inte bara en produktetikett. Den är ett livscykelåtagande som påverkar sårbarhetshantering, tillgång till uppdateringar, hantering av leverantörsberoenden, kundkommunikation, avtalsmässiga utfästelser och eftermarknadsövervakning. För SaaS-leverantörer, enhetstillverkare, programvaruutgivare, molnleverantörer och IKT-tjänsteleverantörer blir supportperioden ett efterlevnadsobjekt som revisorer och reglerade köpare kommer att testa.

Det praktiska svaret är inte ytterligare ett frikopplat kalkylblad för efterlevnad. Svaret är att styra säkerhetssupportperioden inom ett ledningssystem för informationssäkerhet enligt ISO/IEC 27001:2022 och därefter mappa samma underlag till NIS2, DORA, GDPR, NIST CSF 2.0 och COBIT-liknande revisionsförväntningar.

Det är Clarysecs operativa modell: använd ISMS som motor för revisionsunderlag, använd bindande policyer för att definiera ansvar, använd Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint för att bygga spårbarhet och använd Zenith Controls: The Cross-Compliance Guide Zenith Controls som kompass för efterlevnad av flera regelverk.

Varför säkerhetssupportperioden nu är ett revisionsobjekt

En säkerhetssupportperiod besvarar en enkel fråga: hur länge kommer tillverkaren att tillhandahålla säkerhetsuppdateringar, åtgärdande av sårbarheter, vägledning för riskreducering och relaterad kundsupport för en produkt eller produktversion?

I praktiken beror svaret på många rörliga delar:

• Produktarkitektur och underhållbarhet
• Support för tredjepartskomponenter och beroenden med öppen källkod
• Åtaganden från leverantörer och molntjänster
• Processer för mottagning, triagering, åtgärdande och rapportering av sårbarheter
• Kapacitet för releasehantering och testning
• Kunders avtalsvillkor och regulatoriska skyldigheter
• Processer för incidentrespons och underrättelser till tjänstemottagare
• Bevarande av underlag och godkännandeposter

Om en tillverkare utlovar fem års säkerhetssupport, men ett kritiskt kryptografiskt bibliotek upphör att ha support efter tre år, blir supportperioden ett riskbeslut. Om kunden är en finansiell entitet som omfattas av DORA blir samma supportperiod en del av IKT-tredjepartsförsäkran. Om produkten behandlar personuppgifter kan programvara utan support bli en del av ansvarsskyldigheten för säkerhet i behandlingen enligt GDPR. Om produkten stödjer en väsentlig eller viktig entitet enligt NIS2 blir livscykelsäkerhet en fråga om säkerhet i leveranskedjan.

NIS2 gör denna styrningsaspekt uttrycklig. Article 20 kräver att ledningsorgan för väsentliga och viktiga entiteter godkänner riskhanteringsåtgärder för cybersäkerhet, övervakar genomförandet och får utbildning. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning, säker utveckling och underhåll, sårbarhetshantering och sårbarhetsrapportering, effektivitetsbedömning, cyberhygien, kryptografi, åtkomstkontroll, tillgångshantering och autentisering. Article 23 lägger till stegvisa rapporteringsskyldigheter för betydande incidenter.

DORA skapar ett liknande tryck för finansiella entiteter. Förordningen kräver IKT-riskhantering, testning av digital operativ motståndskraft, incidenthantering och styrning av IKT-tredjepartsrisker. DORA Article 28 omfattar principer för IKT-tredjepartsriskhantering, och Article 30 kräver skriftliga avtalsarrangemang med tydliga tjänstebeskrivningar, säkerhetsåtgärder, incidentstöd, revisionsrätt, rätt att säga upp avtalet och exitupplägg.

GDPR lägger till dataskyddslagret. Om produkten behandlar personuppgifter behöver personuppgiftsansvariga och personuppgiftsbiträden lämpliga tekniska och organisatoriska åtgärder enligt Article 32, tydlighet i avtal enligt Article 28 samt beredskap för bedömning och anmälan av personuppgiftsincidenter enligt Articles 33 and 34.

Därför måste säkerhetssupportperioden enligt CRA styras som en kontrollfamilj inom ISMS, inte hanteras som ett isolerat fält i produktförvaltningen.

ISO 27001 som kontrollryggrad för säkerhetssupportperioder enligt CRA

ISO/IEC 27001:2022 är värdefull eftersom standarden är skalbar, riskbaserad och inriktad på ledningssystem. Den kräver att organisationen definierar kontext, intressenter, omfattning och samverkande processer och därefter översätter rättsliga, regulatoriska och avtalsmässiga krav till riskbedömning, riskbehandling, operativa kontroller och underlag ISO/IEC 27001:2022.

För styrning av säkerhetssupportperioder innebär detta att organisationen ska:

1. Identifiera produkter, versioner, moduler, molntjänster och beroenden inom omfattningen.
2. Identifiera intressenter, inklusive kunder, tillsynsmyndigheter, distributörer, importörer, integratörer, personuppgiftsbiträden, underbiträden, partner för incidentrespons och leverantörer.
3. Registrera rättsliga, regulatoriska och avtalsmässiga supportskyldigheter.
4. Bedöma risker som kan hindra att supportåtaganden uppfylls.
5. Välja kontroller för hantering av sårbarheter, säker utveckling, leverantörsförsäkran, incidenthantering, verksamhetskontinuitet, dataskydd och dokumenterad information.
6. Skapa anteckningar i tillämpbarhetsförklaringen (Statement of Applicability, SoA) som förklarar varför kontrollerna är tillämpliga.
7. Granska supportperioden när arkitektur, leverantörsberoenden, hotexponering eller kundåtaganden ändras.

Zenith Controls identifierar tre ämnesrelaterade ISO/IEC 27002:2022-kontroller som centrala fästpunkter för denna styrningsfråga: 5.31 Rättsliga, lagstadgade, regulatoriska och avtalsmässiga krav, 8.8 Hantering av tekniska sårbarheter och 8.25 Säker utvecklingslivscykel. De är inte de enda kontrollerna som berörs, men de utgör styrningsryggraden.

Nyckeln är spårbarhet. En produkts supportperiod bör vara spårbar från skyldighet till riskscenario, från riskscenario till valda kontroller, från kontroller till policykrav och från policykrav till underlag.

Zenith Blueprint, riskhanteringsfasen, steg 13, beskriver denna spårbarhetsdisciplin direkt:

“Korsreferera regelverk: Om vissa kontroller införs särskilt för att uppfylla GDPR, NIS2 eller DORA kan du notera detta antingen i riskregistret (som en del av motiveringen till riskens påverkan) eller i SoA-anteckningarna.”

Källa: Zenith Blueprint: An Auditor’s 30-Step Roadmap, riskhanteringsfasen, steg 13: planering av riskbehandling och tillämpbarhetsförklaring Zenith Blueprint

För en säkerhetssupportperiod enligt CRA bör tillämpbarhetsförklaringen inte bara säga “hantering av sårbarheter är tillämplig”. Den bör förklara att hantering av sårbarheter är tillämplig eftersom företaget har livscykelåtaganden enligt CRA, NIS2-förväntningar på säker utveckling och leveranskedja, krav från DORA-kunder i leverantörsgranskning, säkerhetsskyldigheter enligt GDPR där personuppgifter behandlas samt avtalsmässiga supportlöften.

Från supportlöfte till styrd livscykel

En säkerhetssupportperiod som definieras av tillverkaren bör klara sex styrningstester.

För det första ska den vara definierad. Organisationen behöver en standardiserad taxonomi, exempelvis aktiv support, endast säkerhetssupport, utökad support, begränsad support och utan support. Varje status ska förklara tillgång till uppdateringar, sårbarhetshantering, kundkommunikation och eskaleringsvägar.

För det andra ska den vara riskbedömd. Fem års support för en molnhanterad SaaS-produkt med styrda uppdateringskanaler skiljer sig från fem års support för en inbyggd enhet med begränsningar i fält, tredjepartsberoenden av chip och driftsättningsfönster som kunden hanterar.

För det tredje ska den vara godkänd. Produkt, säkerhet, juridik, dataskydd, kundsupport och ansvarig ledning ska godkänna basperioden och undantagen.

För det fjärde ska den kommuniceras. Kunder ska förstå supportens startdatum, slutdatum, uppdateringsmetod, kanal för sårbarhetsrapportering, förväntningar på åtgärdande, konsekvenser när supporten upphör och tillgängliga förlängningsalternativ.

För det femte ska den övervakas. Beroenden förändras. Leverantörer slutar underhålla bibliotek. Sårbarheter uppstår. Kundmiljöer förändras. Styrning av supportperioder ska omfatta övervakning av komponenters livscykel, leverantörsgranskning, sårbarhetsflöden, patchloggar, releasetestning och erfarenhetsåterföring från incidenter.

För det sjätte ska den kunna styrkas med underlag. Om en revisor, tillsynsmyndighet eller reglerad kund begär bevis ska organisationen kunna visa register över regelefterlevnadskrav, produktens supportregister, riskbedömning, SoA-mappning, sårbarhetsregister, patchposter, leverantörsgranskningar, releasegodkännanden och kundmeddelanden.

Clarysecs policyer gör detta praktiskt. Enterprise Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy kräver:

“Alla rättsliga och regulatoriska skyldigheter måste mappas till specifika policyer, kontroller och ägare inom ledningssystemet för informationssäkerhet (ISMS).”

Källa: Legal and Regulatory Compliance Policy, krav för genomförande av policyn, klausul 6.2.1 Legal and Regulatory Compliance Policy

För små och medelstora företag börjar motsvarande disciplin med ett enklare register. SME Legal and Regulatory Compliance Policy-sme Legal and Regulatory Compliance Policy - SME anger:

“Den verkställande chefen måste upprätthålla ett enkelt, strukturerat register över regelefterlevnadskrav som listar:”

Källa: Legal and Regulatory Compliance Policy-sme, styrningskrav, klausul 5.1.1 Legal and Regulatory Compliance Policy - SME

Ett åtagande om supportperiod ska finnas i registret över regelefterlevnadskrav om det drivs av lag, kundavtal, sektorsreglering eller förväntningar från reglerade köpare. Det ska inte bara finnas i versionsinformation eller marknadsmaterial.

Bygg ett register över säkerhetssupportperioder enligt CRA i en workshop

Föreställ dig en SaaS-leverantör som säljer en uppkopplad analysappliance till logistikleverantörer i EU och kunder i finanssektorn. Produkten innehåller en inbyggd agent, ett moln-API, en mobil administratörsapp och flera bibliotek med öppen källkod. Försäljning vill utlova fem års säkerhetssupport för varje större appliance-version.

Informationssäkerhetschefen kan genomföra en fokuserad workshop med produkt, teknik, juridik, dataskydd och leverantörshantering.

Steg 1: Skapa registret över supportperioder

Skapa en rad per produktversion och inkludera:

• Produkt och version
• Releasedatum
• Startdatum för support
• Standardslutdatum för säkerhetssupport
• Alternativ för utökad support
• Metod för leverans av uppdateringar
• Kanal för sårbarhetsrapportering
• Mål för kritisk patch
• Roll vid behandling av personuppgifter, exempelvis personuppgiftsansvarig, personuppgiftsbiträde eller båda
• Kritiska leverantörer och komponenter
• Berörda kundsektorer
• Riskägare
• Godkännandedatum
• Plats för underlag

Detta register blir dokumenterad information inom ISMS. Zenith Blueprint, fasen ISMS-grund och ledarskap, steg 6, anger förväntan på dokumentstyrning:

“Dokument bör ha korrekt identifiering (en titel, eventuellt ett dokumentnummer eller en unik identifierare, en författare), lämpligt format samt granskning och godkännande av ändamålsenlighet före användning.”

Källa: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fasen ISMS-grund och ledarskap, steg 6: dokumenterad information och uppbyggnad av ISMS-biblioteket Zenith Blueprint

Clarysecs Enterprise PIMS Documented Information Evidence Management Policy PIMS Documented Information Evidence Management Policy tillämpar liknande underlagsprinciper på dataskyddsdokumentation:

“[Alla] Integritetsansvarig / PIMS-ansvarig MÅSTE tilldela dokumentidentifierare, ägare, versionsnummer, godkännandestatus, ikraftträdandedatum och granskningsdatum i REG12 innan PIMS-dokumenterad information publiceras.”

Källa: PIMS Documented Information Evidence Management Policy, skapande, godkännande, versionshantering och publicering, klausul 4.2.1 PIMS Documented Information Evidence Management Policy

Även om registret över supportperioder inte som standard är ett dataskyddsdokument gäller samma disciplin: ägare, version, godkännande, ikraftträdandedatum och granskningsdatum.

Steg 2: Koppla supportlöften till riskbehandling

Skapa riskscenarier för varje produktversion, exempelvis:

• En kritisk sårbarhet upptäcks i en version med support, men teknisk kapacitet saknas.
• En tredjepartskomponent blir utan support innan den deklarerade säkerhetssupportperioden upphör.
• En leverantör ändrar driftplats eller underleverantör och påverkar leveransen av uppdateringar.
• En sårbarhet påverkar personuppgifter och utlöser bedömning av personuppgiftsincident.
• En reglerad finansiell kund kräver underlag för IKT-tredjepartsresiliens.

ISO/IEC 27001:2022 klausuler 6.1.1 till 6.1.3 ger planeringsmotorn: identifiera risker, bedöm sannolikhet och konsekvenser, utse riskägare, välj riskbehandlingar, jämför valda kontroller med Annex A, ta fram tillämpbarhetsförklaringen och inhämta godkännande av kvarstående risk.

För risken “komponent utan support före supportens slutdatum” bör riskposten inkludera ISO/IEC 27002:2022-kontrollerna 5.31, 8.8 och 8.25 samt leverantörskontroller såsom 5.19 Informationssäkerhet i leverantörsrelationer, 5.20 Hantering av informationssäkerhet i leverantörsavtal, 5.21 Hantering av informationssäkerhet i IKT-leveranskedjan och 5.22 Övervakning, granskning och ändringshantering av leverantörstjänster.

Steg 3: Fastställ regler för sårbarhets- och patchunderlag

En supportperiod är trovärdig endast om hantering av sårbarheter fungerar under perioden.

SME Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy - SME anger ett skarpt krav för akut exponering:

“Kritiska patchar måste appliceras inom 3 dagar från release, särskilt för internetexponerade system”

Källa: Vulnerability and Patch Management Policy-sme, krav för genomförande av policyn, klausul 6.1.1 Vulnerability and Patch Management Policy - SME

Den kräver också revisionsklara poster:

“En patchlogg måste upprätthållas och granskas vid revisioner och incidenthanteringsaktiviteter”

Källa: Vulnerability and Patch Management Policy-sme, styrningskrav, klausul 5.4.1 Vulnerability and Patch Management Policy - SME

För större organisationsmiljöer kräver Enterprise Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy:

“Ett centraliserat register för sårbarhetshantering måste upprätthållas av säkerhetsdriftsgruppen och granskas månadsvis av informationssäkerhetschefen eller delegerad befogenhet.”

Källa: Vulnerability and Patch Management Policy, styrningskrav, klausul 5.1 Vulnerability and Patch Management Policy

Zenith Blueprint, fasen kontroller i praktiken, steg 19, förklarar den operativa förväntan bakom ISO/IEC 27002:2022 kontroll 8.8:

“Håll dig informerad om nya säkerhetsbrister (via leverantörslarm, CVE-flöden osv.) för din programvara och hårdvara. Bedöm vilka som är relevanta (använder vi denna programvara? hur kritisk är bristen?) och applicera snabbt korrigeringar eller riskreducerande åtgärder.”

Källa: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fasen kontroller i praktiken, steg 19: tekniska kontroller I Zenith Blueprint

Varje produktversion med support behöver ett underlagsspår för sårbarheter: mottagning, relevansanalys, allvarlighetsgrad, berörda versioner, åtgärdsplan, korrigerande release, vägledning för riskreducering, kundkommunikation och godkännande av avslut.

Steg 4: Koppla säker utveckling till supportens längd

Säkerhetssupport börjar före release. Den bygger på utvecklingspraxis som gör produkten möjlig att underhålla.

SME Secure Development Policy-sme Secure Development Policy - SME anger:

“Komponenter måste uppdateras regelbundet när säkerhetspatchar släpps. Om en kritisk sårbarhet identifieras måste komponenten uppgraderas eller ersättas omedelbart.”

Källa: Secure Development Policy-sme, krav för genomförande av policyn, klausul 6.6.3 Secure Development Policy - SME

SME Application Security Requirements Policy-sme Application Security Requirements Policy - SME kräver att avtal och krav:

“anger skyldigheter för sårbarhetsrapportering, svarstider och patchning.”

Källa: Application Security Requirements Policy-sme, styrningskrav, klausul 5.3.2 Application Security Requirements Policy - SME

Om företaget utlovar support till 2031 måste arkitekturen stödja underhållbara uppdateringar, utbyte av beroenden, säkra byggpipelines, regressionstestning och akuta releaser. ISO/IEC 27002:2022-kontroller för säker utveckling, säker arkitektur, säker kodning, säkerhetstestning, outsourcad utveckling, separering av miljöer och ändringshantering blir möjliggörare för supportperioden.

Ett underlag för CRA, NIS2, DORA och GDPR

Samma underlag för supportperioder kan stödja olika regulatoriska samtal, men varje ramverk ställer frågan på olika sätt.

Leverantörsberoenden är ofta där supportåtaganden fallerar. Enterprise Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy kräver:

“Register över leverantörsberoenden: VMO ska upprätthålla ett aktuellt register över alla kritiska leverantörer, inklusive uppgifter såsom tillhandahållna tjänster/produkter, om leverantören är enda källa, tillgängliga alternativa leverantörer eller utbytbarhet, aktuella avtalsvillkor och en bedömning av påverkan om leverantören skulle fallera eller komprometteras.”

Källa: Supplier Dependency Risk Management Policy, genomförandekrav, klausul 6.1 Supplier Dependency Risk Management Policy

Zenith Blueprint, fasen kontroller i praktiken, steg 23, varnar för att revisorer kommer att granska leverantörsavtal och underlag för leverantörsuppföljning:

“Revisorer kommer att granska exempel på avtal eller tjänsteöverenskommelser. De letar efter uttryckliga informationssäkerhetsklausuler, såsom tidslinjer för incidentanmälan, åtkomstbegränsningar, skyldigheter vid behandling av personuppgifter, krypteringskrav eller revisionsrätt.”

Källa: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fasen kontroller i praktiken, steg 23: organisatoriska kontroller Zenith Blueprint

För DORA-kunder är detta kritiskt. Avtal för IKT-tjänster som stödjer kritiska eller viktiga funktioner behöver tydliga tjänstebeskrivningar, villkor för underleverantörer, säkerhetsåtgärder, incidentstöd, revisions- och inspektionsrättigheter, rätt att säga upp avtalet och övergångsupplägg. En leverantör som inte kan stödja dessa åtaganden kan hindra tillverkaren från att lämna ett trovärdigt löfte om supportperiod.

Kontrollmappning för revisionsklar styrning av supportperioder

Denna kontrollmappning gör att säkerhet, juridik, produkt och försäljning kan tala samma språk. Registret över supportperioder är inte bara CRA-underlag. Det är leverantörsförsäkran för NIS2, tredjepartsförsäkran för DORA, stöd för säkerhet i behandlingen enligt GDPR och en styrningsartefakt för ISO 27001-certifiering.

Dataskyddsperspektivet: när avsaknad av support blir osäkert

Styrning av säkerhetssupportperioder är inte bara en cybersäkerhetsfråga. Om produkten lagrar, överför eller behandlar personuppgifter kan programvara utan support bli en integritetsrisk.

GDPR gäller behandling inom ramen för en etablering i EU och kan även gälla organisationer utanför EU som erbjuder varor eller tjänster till personer i EU eller övervakar deras beteende. Förordningen definierar personuppgifter brett och behandlar en personuppgiftsincident som en säkerhetsöverträdelse som leder till oavsiktlig eller olaglig förstöring, förlust, ändring, obehörigt röjande av eller åtkomst till behandlade personuppgifter.

För styrning av supportperioder behöver dataskyddsteam veta vilka produktversioner som behandlar personuppgifter (PII), vilka system som fortfarande har support och om sårbarheter påverkar konfidentialitet, riktighet eller tillgänglighet för personuppgifter.

Clarysecs Enterprise PII Security Access Control Policy PII Security Access Control Policy kräver:

“[Båda] Systemägare / applikationsägare MÅSTE registrera täckning för sårbarhetsbedömning för system som behandlar PII i REG12 minst kvartalsvis och efter väsentlig teknisk ändring.”

Källa: PII Security Access Control Policy, säker konfiguration och sårbarhetshantering, klausul 4.7.4 PII Security Access Control Policy

Enterprise Processor Subprocessor Third Party Privacy Management Policy Processor Subprocessor Third Party Privacy Management Policy lägger till löpande uppföljning för högriskrelationer inom dataskydd:

“[Alla] Leverantörs-/upphandlingsägaren MÅSTE följa upp aktiva högriskrelationer med personuppgiftsbiträden och underbiträden kvartalsvis och andra aktiva PII-relationer med personuppgiftsbiträden och underbiträden årligen mot villkor för leverantörsgranskning, avtalsstatus, försäkransstatus, öppna frågor och granskningsdatum i REG08.”

Källa: Processor Subprocessor Third Party Privacy Management Policy, löpande uppföljning, stöd, utlämnandegränssnitt och avslut, klausul 4.5.1 Processor Subprocessor Third Party Privacy Management Policy

När en sårbarhet blir en incident kräver Enterprise PII Incident Breach Management Policy PII Incident Breach Management Policy bedömning av rapporterings- och anmälningsplikt över flera ramverk:

“[Villkorligt] Integritetsansvarig / PIMS-ansvarig MÅSTE utvärdera tillämpliga rättsliga, sektoriella, finanssektorsrelaterade, cybersäkerhetsrelaterade, avtalsmässiga, kundrelaterade och tjänstemottagarrelaterade rapporteringsutlösare för varje PII-incident med hög påverkan och registrera utfallet av tillämpligheten i REG01, REG08 och REG10.”

Källa: PII Incident Breach Management Policy, klassificering och bedömning av personuppgiftsincident, klausul 4.2.6 PII Incident Breach Management Policy

Detta är den praktiska överlappningen mellan supportåtaganden enligt CRA, incidentkommunikation enligt NIS2, hantering av större IKT-incidenter enligt DORA och ansvarsskyldighet för personuppgiftsincidenter enligt GDPR.

Hur revisorer testar samma supportperiodsprocess

En stark styrningsprocess för supportperioder bör klara flera revisionsperspektiv. Underlaget ändras inte mycket, men revisorns perspektiv gör det.

NIST CSF 2.0 är användbart som kommunikationslager eftersom dess GOVERN-funktion omfattar rättsliga, regulatoriska, avtalsmässiga och integritetsrelaterade skyldigheter, riskhanteringsmål, riskaptit, roller, policyer och tillsyn. Dess utfall för leveranskedjan omfattar leverantörsstrategi, kritikalitet, avtal, leverantörsgranskning, uppföljning, incidentsamordning och bestämmelser för relationens upphörande.

COBIT- och ISACA-inriktade revisorer fokuserar ofta på styrningens utformning: vem äger beslutet, vilken process är definierad, vilka mätetal visar prestation, hur undantag godkänns och hur ständig förbättring hanteras.

Clarysecs Enterprise Information Security Policy Information Security Policy fångar principen om revisionsbarhet:

“Alla införda kontroller ska vara möjliga att granska, stödjas av dokumenterade rutiner och ha bevarat underlag för drift.”

Källa: Information Security Policy, krav för genomförande av policyn, klausul 6.6.1 Information Security Policy

Det är den mening som varje säkerhetssupportperiod bör kunna uppfylla.

Förläng, förkorta eller avsluta support utan att skapa falsk försäkran

De svåraste styrningsögonblicken inträffar inte vid produktlansering. De uppstår när verkligheten förändras.

Ni kan behöva förlänga support eftersom reglerade kunder är beroende av produkten, migrering inte är möjlig eller en kund i en viss sektor har avtalsmässiga kontinuitetsbehov. Ni kan behöva förkorta eller begränsa support eftersom en leverantör upphör med säkerhetsunderhåll, en komponent blir omöjlig att patcha, en plattform når tekniska gränser eller produktarkitekturen inte säkert kan stödja en viss sårbarhetsklass.

En styrd ändring av supportperioden ska inkludera:

• Ändringsutlösare, såsom leverantörens livscykelavslut, kritisk sårbarhet, kundavtal eller regulatorisk ändring
• Berörda produkter, versioner, kunder och sektorer
• Påverkansanalys för personuppgifter och kritiska tjänster
• Genomförbarhetsgranskning av leverantörer och komponenter
• Riskbedömning och beslut om kvarstående risk
• Uppdaterat register över supportperioder
• Uppdaterat kundmeddelande och avtalsmässig position
• Uppdaterade SoA-anteckningar där kontroller eller skyldigheter ändras
• Ledningsgodkännande och granskningsdatum

Enterprise Coordinated Vulnerability Disclosure Policy Coordinated Vulnerability Disclosure Policy är användbar när ändringen drivs av en sårbarhet:

“En plan för åtgärdande eller riskreducering ska tas fram för alla bekräftade sårbarheter. Genomförandet av korrigeringen ska prioriteras utifrån allvarlighetsgrad. Exempelvis ska kritiska sårbarheter åtgärdas eller riskreduceras inom 14 dagar där det är genomförbart, eller snabbare när aktiv exploatering upptäcks, medan problem med lägre allvarlighetsgrad ska hanteras inom rimlig tid.”

Källa: Coordinated Vulnerability Disclosure Policy, genomförandekrav, klausul 6.6 Coordinated Vulnerability Disclosure Policy

Om en fullständig korrigering inte kan levereras omedelbart kan kompenserande kontroller, inaktiverad funktionalitet, ökad övervakning eller vägledning till kunder om konfiguration vara tillfälligt acceptabla, men beslutet måste dokumenteras och kommuniceras.

Praktisk Clarysec-checklista för beredskap avseende supportperioder

Använd denna checklista innan ni publicerar eller förnyar ett åtagande om säkerhetssupportperiod enligt CRA.

• Finns produkten och versionen i registret över supportperioder?
• Är supportens slutdatum godkänt av produkt, säkerhet och ansvarig ledning?
• Är rättsliga, regulatoriska och avtalsmässiga drivkrafter mappade i registret över regelefterlevnadskrav?
• Ingår riskscenariot för supportperioden i riskregistret?
• Är kontroller mappade i tillämpbarhetsförklaringen, inklusive 5.31, 8.8 och 8.25 där det är tillämpligt?
• Är kritiska leverantörer och komponenter mappade i registret över leverantörsberoenden?
• Finns det underlag för att komponenter kan patchas eller ersättas under supportperioden?
• Är ansvar för mottagning, triagering, åtgärdande och rapportering av sårbarheter definierat?
• Är SLA:er för kritiska patchar anpassade till policy och kundavtal?
• Bevaras patchloggar, releaseposter och sårbarhetsbeslut?
• Täcks system med personuppgifter av underlag för sårbarhetsbedömning där PII behandlas?
• Är kundmeddelanden, supportuttalanden och avtalsvillkor konsekventa?
• Finns det en process för att förlänga, förkorta eller avsluta support med riskgodkännande?
• Får ledningens genomgång indata om risker för supportperioder, leverantörer, sårbarheter och incidenter?
• Kan underlag tas fram inom 48 timmar för en kundrevision eller myndighetsförfrågan?

Enterprise PIMS Monitoring Audit Improvement Policy PIMS Monitoring Audit Improvement Policy förstärker disciplinen för ledningens genomgång i dataskyddsprogram:

“[Båda] Högsta ledningen MÅSTE granska PIMS-avvikelser, korrigerande åtgärder, övervakningsresultat, revisionsresultat, integritetsrisker, leverantörsförsäkran och indata om ändringar hos intressenter i REG12 vid varje ledningens genomgång.”

Källa: PIMS Monitoring Audit Improvement Policy, ledningens genomgång av PIMS, klausul 4.3.5 PIMS Monitoring Audit Improvement Policy

För styrning av säkerhetssupportperioder bör samma granskningsrytm gälla i hela ISMS: sårbarheter, patchprestanda, leverantörsförsäkran, kundåtaganden, incidenter, supportundantag och korrigerande åtgärder bör ingå i ledningens genomgång.

Gör säkerhetssupportperioden försvarbar

EU:s cyberresiliensförordning (CRA) förändrar synsättet på produktsäkerhet. Den driver tillverkare och programvaruleverantörer att tänka längre än releasedagen. Säkerhetssupportperioden blir ett livscykellöfte som måste konstrueras, styras, övervakas och styrkas med underlag.

För informationssäkerhetschefer är lärdomen tydlig: låt inte supportperioden endast finnas i produktmarknadsföringen. För complianceansvariga: bygg inte en separat CRA-underlagssilo. För revisorer: testa om supportåtaganden är spårbara till risk, kontroller, leverantörer, incidenter och dokumenterade godkännanden. För verksamhetsägare: kom ihåg att en trovärdig supportperiod kan bli en marknadsfördel, särskilt vid försäljning till NIS2-reglerade sektorer, finansiella entiteter enligt DORA och kunder med höga krav på dataskydd.

Clarysec hjälper organisationer att operationalisera detta genom:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint för att bygga ISMS-spårbarhet, dokumenterad information, SoA-mappning och revisionsberedskap
• Zenith Controls: The Cross-Compliance Guide Zenith Controls för att mappa ISO/IEC 27002:2022-kontroller till NIS2, DORA, GDPR, NIST CSF 2.0 och revisionsförväntningar
• Policy Packs för Enterprise och SME inom hantering av sårbarheter, säker utveckling, efterlevnad av rättsliga krav, leverantörsberoenden, dataskyddsunderlag och incidentrespons
• Praktiska register och underlagsarbetsflöden som gör supportperiodslöften till revisionsbar styrning

Nästa steg är enkelt: välj en flaggskeppsversion av en produkt och bygg dess underlagsfil för säkerhetssupportperioden. Mappa skyldigheten, godkänn supportperioden, testa sårbarhetsprocessen, validera leverantörsberoenden, bekräfta kundkommunikation och bevara posterna.

Om ni kan försvara en produkt kan ni skala modellen. Om ni inte kan försvara en produkt är luckan inte dokumentation. Den är styrning.

Ladda ner Zenith Blueprint, använd Zenith Controls för att mappa ert underlag eller begär en Clarysec-beredskapsbedömning för att omvandla säkerhetssupportperioder enligt CRA till revisionsklar ISO 27001-styrning.