EU CRA-beveiligingsondersteuningsperioden met ISO 27001

Het is 08:20 op een dinsdag wanneer de producteigenaar van een verbonden B2B-gateway een bericht ontvangt van een gereguleerde klant: “Bevestig alstublieft de beveiligingsondersteuningsperiode voor firmwareversie 4.6, de SLA voor kwetsbaarheidsrespons en of het apparaat gedurende ons vijfjarige servicecontract in aanmerking blijft komen voor beveiligingsupdates.”

Om 09:00 heeft Inkoop een DORA-due-diligencevragenlijst doorgestuurd. Om 10:15 vraagt Juridische Zaken of de geadverteerde ondersteuningsperiode overeenkomt met de klantcontracten. Om 11:00 wordt de CISO betrokken bij een NIS2-beoordeling van leveranciersrisico’s, omdat het product door een aanbieder van beheerde diensten in de EU wordt gebruikt. Na de lunch vraagt het privacyteam of een niet-ondersteunde API-bibliotheek in het product gevolgen kan hebben voor de beveiliging van persoonsgegevens onder GDPR.

De ongemakkelijke waarheid wordt snel zichtbaar. De organisatie heeft een roadmap, een patchproces, een releasekalender en een klantondersteuningsportaal, maar beschikt niet over beheerst bewijs voor beveiligingsondersteuningsperioden.

Dat hiaat is relevant. Onder de EU Cyberweerbaarheidsverordening is de beveiligingsondersteuningsperiode niet alleen een productlabel. Het is een levenscyclusverplichting die invloed heeft op kwetsbaarheidsafhandeling, beschikbaarheid van updates, beheer van leveranciersafhankelijkheden, klantcommunicatie, contractuele verklaringen en monitoring na het in de handel brengen. Voor SaaS-leveranciers, apparaatfabrikanten, software-uitgevers, cloudleveranciers en aanbieders van ICT-diensten wordt de ondersteuningsperiode een nalevingsobject dat auditors en gereguleerde afnemers zullen toetsen.

Het praktische antwoord is niet nog een losstaande nalevingsspreadsheet. Het antwoord is om de beveiligingsondersteuningsperiode te beheren binnen een ISO/IEC 27001:2022-managementsysteem voor informatiebeveiliging (ISMS) en hetzelfde bewijs vervolgens te mappen aan NIS2, DORA, GDPR, NIST CSF 2.0 en COBIT-achtige auditverwachtingen.

Dat is het operationele model van Clarysec: gebruik het ISMS als bewijsmachine, gebruik afdwingbaar beleid om verantwoordelijkheden te definiëren, gebruik Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint om traceerbaarheid op te bouwen, en gebruik Zenith Controls: The Cross-Compliance Guide Zenith Controls als kompas voor mapping over meerdere nalevingskaders.

Waarom de beveiligingsondersteuningsperiode nu een auditobject is

Een beveiligingsondersteuningsperiode beantwoordt een eenvoudige vraag: hoe lang zal de fabrikant beveiligingsupdates, remediatie van kwetsbaarheden, mitigatierichtlijnen en gerelateerde klantondersteuning leveren voor een product of productversie?

In de praktijk hangt dat antwoord af van veel bewegende delen:

• Productarchitectuur en onderhoudbaarheid
• Ondersteuning voor componenten van derden en open-sourceafhankelijkheden
• Verplichtingen van leveranciers en clouddiensten
• Processen voor kwetsbaarheidsintake, triage, remediatie en openbaarmaking
• Release-engineering en testcapaciteit
• Klantcontractvoorwaarden en wettelijke verplichtingen
• Incidentrespons en routes voor kennisgeving aan afnemers van diensten
• Bewaring van bewijs en goedkeuringsregistraties

Als een fabrikant vijf jaar beveiligingsondersteuning belooft, maar een kritieke cryptografische bibliotheek na drie jaar niet langer wordt ondersteund, wordt de ondersteuningsperiode een risicobesluit. Als een klant een financiële entiteit is die onder DORA valt, wordt dezelfde ondersteuningsperiode onderdeel van assurance over derde aanbieders van ICT-diensten. Als het product persoonsgegevens verwerkt, kan niet-ondersteunde software onderdeel worden van de verantwoordingsplicht voor beveiliging van de verwerking onder GDPR. Als het product een essentiële of belangrijke entiteit onder NIS2 ondersteunt, wordt levenscyclusbeveiliging een vraagstuk van beveiliging van de toeleveringsketen.

NIS2 maakt deze governance-invalshoek expliciet. Article 20 vereist dat bestuursorganen van essentiële en belangrijke entiteiten cyberbeveiligingsrisicobeheersmaatregelen goedkeuren, toezicht houden op de implementatie en training ontvangen. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentenafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving, veilige ontwikkeling en onderhoud, kwetsbaarheidsafhandeling en openbaarmaking, beoordeling van doeltreffendheid, cyberhygiëne, cryptografie, toegangscontrole, beheer van bedrijfsmiddelen en authenticatie. Article 23 voegt gefaseerde rapportageverplichtingen voor significante incidenten toe.

DORA creëert vergelijkbare druk voor financiële entiteiten. De verordening vereist ICT-risicobeheer, testen van digitale operationele weerbaarheid, incidentbeheer en governance van risico’s van derde aanbieders van ICT-diensten. DORA Article 28 behandelt beginselen voor ICT-risicobeheer met betrekking tot derde partijen, en Article 30 vereist schriftelijke contractuele regelingen met duidelijke dienstbeschrijvingen, beveiligingsmaatregelen, incidentondersteuning, auditrechten, beëindigingsrechten en exitregelingen.

GDPR voegt de privacylaag toe. Als het product persoonsgegevens verwerkt, hebben verwerkingsverantwoordelijken en verwerkers passende technische en organisatorische maatregelen nodig onder Article 32, contractuele duidelijkheid onder Article 28, en paraatheid voor datalekbeoordeling en melding onder Articles 33 en 34.

Daarom moet de CRA-beveiligingsondersteuningsperiode worden beheerd als een ISMS-familie van beheersmaatregelen, niet als een geïsoleerd productmanagementveld.

ISO 27001 als ruggengraat van beheersmaatregelen voor CRA-beveiligingsondersteuningsperioden

ISO/IEC 27001:2022 is waardevol omdat de norm schaalbaar, risicogebaseerd en gericht op managementsystemen is. De norm vereist dat de organisatie context, belanghebbenden, scope en op elkaar inwerkende processen definieert, en vervolgens wettelijke, regelgevende en contractuele eisen vertaalt naar risicobeoordeling, risicobehandeling, operationele beheersmaatregelen en bewijs ISO/IEC 27001:2022.

Voor governance van beveiligingsondersteuningsperioden betekent dit dat de organisatie het volgende moet doen:

1. Producten, versies, modules, clouddiensten en afhankelijkheden binnen scope identificeren.
2. Belanghebbenden identificeren, waaronder klanten, toezichthouders, distributeurs, importeurs, integratoren, verwerkers, subverwerkers, incidentresponspartners en leveranciers.
3. Wettelijke, regelgevende en contractuele ondersteuningsverplichtingen registreren.
4. Risico’s beoordelen die kunnen verhinderen dat ondersteuningsverplichtingen worden nagekomen.
5. Beheersmaatregelen selecteren voor kwetsbaarhedenbeheer, veilige ontwikkeling, leveranciersassurance, incidentbeheer, bedrijfscontinuïteit, privacy en gedocumenteerde informatie.
6. Notities bij de Verklaring van Toepasselijkheid opstellen waarin wordt uitgelegd waarom beheersmaatregelen van toepassing zijn.
7. De ondersteuningsperiode beoordelen wanneer architectuur, leveranciersafhankelijkheden, dreigingsblootstelling of klantverplichtingen wijzigen.

Zenith Controls identificeert drie thematisch relevante beheersmaatregelen uit ISO/IEC 27002:2022 als centrale ankers voor dit governancevraagstuk: 5.31 Wettelijke, statutaire, regelgevende en contractuele eisen, 8.8 Beheer van technische kwetsbaarheden, en 8.25 Veilige ontwikkelingslevenscyclus. Dit zijn niet de enige betrokken beheersmaatregelen, maar zij vormen de governance-ruggengraat.

De sleutel is traceerbaarheid. Een productondersteuningsperiode moet traceerbaar zijn van verplichting naar risicoscenario, van risicoscenario naar geselecteerde beheersmaatregelen, van beheersmaatregelen naar beleidsvereisten, en van beleidsvereisten naar bewijs.

Zenith Blueprint, fase Risk Management, Step 13, beschrijft deze traceerbaarheidsdiscipline rechtstreeks:

“Verwijs regelgeving kruislings: als bepaalde beheersmaatregelen specifiek zijn geïmplementeerd om te voldoen aan GDPR, NIS2 of DORA, kunt u dit opnemen in het risicoregister (als onderdeel van de onderbouwing van de risico-impact) of in de SoA-notities.”

Bron: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Risk Management, Step 13: Risk Treatment Planning and Statement of Applicability Zenith Blueprint

Voor een CRA-beveiligingsondersteuningsperiode mag de Verklaring van Toepasselijkheid niet alleen zeggen: “kwetsbaarhedenbeheer is van toepassing”. Zij moet uitleggen dat kwetsbaarhedenbeheer van toepassing is omdat de organisatie CRA-levenscyclusverplichtingen heeft, NIS2-verwachtingen voor veilige ontwikkeling en toeleveringsketens, DORA-eisen voor klant-due diligence, GDPR-beveiligingsverplichtingen waar persoonsgegevens worden verwerkt, en contractuele ondersteuningsbeloften.

Van ondersteuningsbelofte naar beheerste levenscyclus

Een door de fabrikant vastgestelde beveiligingsondersteuningsperiode moet zes governancetoetsen doorstaan.

Ten eerste moet zij zijn gedefinieerd. De organisatie heeft een standaardtaxonomie nodig, zoals actieve ondersteuning, uitsluitend beveiligingsondersteuning, uitgebreide ondersteuning, beperkte ondersteuning en niet-ondersteund. Elke status moet beschikbaarheid van updates, kwetsbaarheidsafhandeling, klantcommunicatie en escalatiepaden toelichten.

Ten tweede moet zij risicobeoordeeld zijn. Vijf jaar ondersteuning voor een in de cloud beheerd SaaS-product met gecontroleerde updatekanalen is anders dan vijf jaar voor een embedded device met beperkingen in het veld, chipafhankelijkheden van derden en door de klant beheerde implementatievensters.

Ten derde moet zij zijn goedgekeurd. Product, beveiliging, Juridische Zaken, privacy, klantenondersteuning en het verantwoordelijke management moeten de basisperiode en uitzonderingen goedkeuren.

Ten vierde moet zij worden gecommuniceerd. Klanten moeten de startdatum van ondersteuning, einddatum, updatemethode, meldkanaal voor kwetsbaarheden, remediatieverwachtingen, gevolgen van einde ondersteuning en beschikbare verlengingsopties begrijpen.

Ten vijfde moet zij worden gevolgd. Afhankelijkheden wijzigen. Leveranciers beëindigen bibliotheken. Kwetsbaarheden ontstaan. Klantomgevingen veranderen. Governance van ondersteuningsperioden moet monitoring van de componentlevenscyclus, leveranciersbeoordeling, kwetsbaarheidsfeeds, patchlogboeken, releasetesten en lessen uit incidenten omvatten.

Ten zesde moet zij aantoonbaar zijn. Als een auditor, toezichthouder of gereguleerde klant om bewijs vraagt, moet de organisatie het nalevingsregister, productondersteuningsregister, risicobeoordeling, SoA-mapping, kwetsbaarhedenregister, patchregistraties, leveranciersbeoordelingen, releasegoedkeuringen en klantkennisgevingen kunnen tonen.

Clarysec-beleid maakt dit praktisch. Het enterprise Beleid inzake juridische en regelgevende naleving Beleid inzake juridische en regelgevende naleving vereist:

“Alle wettelijke en regelgevende verplichtingen moeten worden gemapt aan specifieke beleidsdocumenten, beheersmaatregelen en eigenaren binnen het Information Security Management System (ISMS).”

Bron: Beleid inzake juridische en regelgevende naleving, Vereisten voor beleidsimplementatie, clausule 6.2.1 Beleid inzake juridische en regelgevende naleving

Voor mkb-organisaties begint de vergelijkbare discipline met een eenvoudiger register. Het mkb Legal and Regulatory Compliance Policy-sme Beleid inzake juridische en regelgevende naleving - mkb bepaalt:

“De algemeen directeur moet een eenvoudig, gestructureerd nalevingsregister bijhouden met daarin:”

Bron: Legal and Regulatory Compliance Policy-sme, Governancevereisten, clausule 5.1.1 Beleid inzake juridische en regelgevende naleving - mkb

Een verplichting rond een ondersteuningsperiode hoort in het nalevingsregister als zij voortkomt uit wetgeving, een klantcontract, sectorspecifieke regelgeving of verwachtingen van een gereguleerde afnemer. Zij mag niet alleen in release notes of marketingteksten staan.

Bouw een CRA-register voor beveiligingsondersteuningsperioden in één workshop

Stel u een SaaS-leverancier voor die een verbonden analyse-appliance verkoopt aan logistieke dienstverleners in de EU en klanten in de financiële sector. Het product bevat een embedded agent, een cloud-API, een mobiele beheerapp en meerdere open-sourcebibliotheken. Sales wil vijf jaar beveiligingsondersteuning beloven voor elke majeure applianceversie.

De CISO kan een gerichte workshop uitvoeren met Product, Engineering, Juridische Zaken, Privacy en Leveranciersmanagement.

Stap 1: Maak het register voor ondersteuningsperioden

Maak één rij per productversie en neem op:

• Product en versie
• Releasedatum
• Startdatum van ondersteuning
• Standaard einddatum voor beveiligingsondersteuning
• Optie voor uitgebreide ondersteuning
• Methode voor levering van updates
• Kanaal voor openbaarmaking van kwetsbaarheden
• Doelstelling voor kritieke patches
• Rol bij gegevensverwerking, zoals verwerkingsverantwoordelijke, verwerker of beide
• Kritieke leveranciers en componenten
• Geraakte klantsectoren
• Risico-eigenaar
• Goedkeuringsdatum
• Locatie van bewijs

Dit register wordt gedocumenteerde informatie binnen het ISMS. Zenith Blueprint, fase ISMS Foundation and Leadership, Step 6, geeft de verwachting voor documentbeheersing:

“Documenten moeten correct zijn geïdentificeerd (een titel, mogelijk een documentnummer of unieke identificatie, een auteur), een passend formaat hebben, en vóór gebruik worden beoordeeld en goedgekeurd op toereikendheid.”

Bron: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase ISMS Foundation and Leadership, Step 6: Documented Information and Building the ISMS Library Zenith Blueprint

Clarysec’s enterprise PIMS Documented Information Evidence Management Policy PIMS-beleid voor beheer van gedocumenteerde informatie en bewijs past vergelijkbare bewijsprincipes toe op privacydocumentatie:

“[All] De Privacy Lead / PIMS Manager MOET een documentidentificatie, eigenaar, versienummer, goedkeuringsstatus, ingangsdatum en beoordelingsdatum in REG12 toewijzen voordat PIMS-gedocumenteerde informatie wordt gepubliceerd.”

Bron: PIMS Documented Information Evidence Management Policy, creatie, goedkeuring, versiebeheer en publicatie, clausule 4.2.1 PIMS-beleid voor beheer van gedocumenteerde informatie en bewijs

Ook als het register voor ondersteuningsperioden standaard geen privacydocument is, geldt dezelfde discipline: eigenaar, versie, goedkeuring, ingangsdatum en beoordelingsdatum.

Stap 2: Koppel ondersteuningsbeloften aan risicobehandeling

Maak voor elke productversie risicoscenario’s, zoals:

• Er wordt een kritieke kwetsbaarheid ontdekt in een ondersteunde versie, maar engineeringcapaciteit is niet beschikbaar.
• Een component van derden wordt niet-ondersteund voordat de verklaarde beveiligingsondersteuningsperiode afloopt.
• Een leverancier wijzigt hostinglocatie of onderaannemer en beïnvloedt de levering van updates.
• Een kwetsbaarheid raakt persoonsgegevens en triggert een datalekbeoordeling.
• Een gereguleerde financiële klant vraagt om bewijs voor weerbaarheid van derde aanbieders van ICT-diensten.

ISO/IEC 27001:2022 clauses 6.1.1 to 6.1.3 bieden de planningsmotor: risico’s identificeren, waarschijnlijkheid en gevolgen beoordelen, risico-eigenaren toewijzen, behandelingen selecteren, geselecteerde beheersmaatregelen vergelijken met Annex A, de Verklaring van Toepasselijkheid opstellen en goedkeuring van restrisico verkrijgen.

Voor het risico “niet-ondersteunde component vóór einddatum ondersteuning” moet de risicoregistratie ISO/IEC 27002:2022-beheersmaatregelen 5.31, 8.8 en 8.25 bevatten, plus leveranciersbeheersmaatregelen zoals 5.19 Informatiebeveiliging in leveranciersrelaties, 5.20 Informatiebeveiliging binnen leveranciersovereenkomsten adresseren, 5.21 Informatiebeveiliging in de ICT-toeleveringsketen beheren, en 5.22 Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten.

Stap 3: Stel bewijsregels voor kwetsbaarheden en patches vast

Een ondersteuningsperiode is alleen geloofwaardig als kwetsbaarhedenbeheer gedurende die periode werkt.

Het mkb Vulnerability and Patch Management Policy-sme Beleid inzake kwetsbaarheden- en patchbeheer - mkb stelt een scherpe eis voor urgente blootstelling:

“Kritieke patches moeten binnen 3 dagen na release worden toegepast, met name voor systemen die vanaf internet bereikbaar zijn”

Bron: Vulnerability and Patch Management Policy-sme, Vereisten voor beleidsimplementatie, clausule 6.1.1 Beleid inzake kwetsbaarheden- en patchbeheer - mkb

Het vereist ook registraties die gereed zijn voor audits:

“Een patchlogboek moet worden bijgehouden en beoordeeld tijdens audits en incidentresponsactiviteiten”

Bron: Vulnerability and Patch Management Policy-sme, Governancevereisten, clausule 5.4.1 Beleid inzake kwetsbaarheden- en patchbeheer - mkb

Voor enterprise-omgevingen vereist het enterprise Beleid inzake kwetsbaarheden- en patchbeheer Beleid inzake kwetsbaarheden- en patchbeheer:

“Een centraal register voor kwetsbaarheden moet worden bijgehouden door het Security Operations Team en maandelijks worden beoordeeld door de CISO of gedelegeerde bevoegde functionaris.”

Bron: Beleid inzake kwetsbaarheden- en patchbeheer, Governancevereisten, clausule 5.1 Beleid inzake kwetsbaarheden- en patchbeheer

Zenith Blueprint, fase Controls in Action, Step 19, licht de operationele verwachting achter ISO/IEC 27002:2022-beheersmaatregel 8.8 toe:

“Blijf geïnformeerd over nieuwe beveiligingsbugs (via leveranciersmeldingen, CVE-feeds, enz.) voor uw software en hardware. Beoordeel welke relevant zijn (gebruiken wij deze software? hoe kritiek is de bug?) en pas fixes of mitigaties tijdig toe.”

Bron: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Controls in Action, Step 19: Technological Controls I Zenith Blueprint

Elke ondersteunde productversie heeft een bewijsspoor voor kwetsbaarheden nodig: intake, relevantieanalyse, ernstclassificatie, getroffen versies, remediatieplan, fixrelease, mitigatierichtlijnen, klantcommunicatie en goedkeuring van afsluiting.

Stap 4: Koppel veilige ontwikkeling aan ondersteuningsduur

Beveiligingsondersteuning begint vóór release. Zij hangt af van ontwikkelpraktijken die het product onderhoudbaar maken.

Het mkb Secure Development Policy-sme Beleid inzake veilige ontwikkeling - mkb bepaalt:

“Componenten moeten regelmatig worden bijgewerkt wanneer beveiligingspatches worden uitgebracht. Als een kritieke kwetsbaarheid wordt geïdentificeerd, moet de component onmiddellijk worden bijgewerkt of vervangen.”

Bron: Secure Development Policy-sme, Vereisten voor beleidsimplementatie, clausule 6.6.3 Beleid inzake veilige ontwikkeling - mkb

Het mkb Application Security Requirements Policy-sme Beleid inzake vereisten voor applicatiebeveiliging - mkb vereist dat contracten en vereisten:

“verplichtingen specificeren voor openbaarmaking van kwetsbaarheden, responstijden en patching.”

Bron: Application Security Requirements Policy-sme, Governancevereisten, clausule 5.3.2 Beleid inzake vereisten voor applicatiebeveiliging - mkb

Als de organisatie ondersteuning tot 2031 belooft, moet de architectuur onderhoudbare updates, vervanging van afhankelijkheden, beveiligde buildpijplijnen, regressietesten en noodreleases ondersteunen. ISO/IEC 27002:2022-beheersmaatregelen voor veilige ontwikkeling, veilige architectuur, veilig programmeren, beveiligingstesten, uitbestede ontwikkeling, scheiding van omgevingen en wijzigingsbeheer worden enablers van de ondersteuningsperiode.

Eén set bewijs voor CRA, NIS2, DORA en GDPR

Hetzelfde bewijs voor ondersteuningsperioden kan verschillende regelgevende gesprekken ondersteunen, maar elk raamwerk stelt de vraag anders.

Leveranciersafhankelijkheid is vaak de plek waar ondersteuningsverplichtingen falen. Het enterprise Beleid inzake beheer van leveranciersafhankelijkheidsrisico’s Beleid inzake beheer van leveranciersafhankelijkheidsrisico’s vereist:

“Register van leveranciersafhankelijkheden: de VMO moet een actueel register bijhouden van alle kritieke leveranciers, met details zoals geleverde diensten/producten; of de leverancier een sole-source-situatie vormt; beschikbare alternatieve leveranciers of vervangbaarheid; actuele contractvoorwaarden; en een beoordeling van de impact als de leverancier zou uitvallen of worden gecompromitteerd.”

Bron: Beleid inzake beheer van leveranciersafhankelijkheidsrisico’s, Implementatievereisten, clausule 6.1 Beleid inzake beheer van leveranciersafhankelijkheidsrisico’s

Zenith Blueprint, fase Controls in Action, Step 23, waarschuwt dat auditors leveranciersovereenkomsten en bewijs voor leveranciersmonitoring zullen inspecteren:

“Auditors zullen steekproeven van contracten of dienstverleningsovereenkomsten beoordelen. Zij zoeken naar expliciete informatiebeveiligingsclausules, zoals meldtermijnen voor inbreuken, toegangsbeperkingen, verplichtingen inzake gegevensverwerking, encryptievereisten of auditrechten.”

Bron: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Controls in Action, Step 23: Organizational controls Zenith Blueprint

Voor DORA-klanten is dit kritiek. Contracten voor ICT-diensten die kritieke of belangrijke functies ondersteunen, hebben duidelijke dienstbeschrijvingen, voorwaarden voor onderuitbesteding, beveiligingsmaatregelen, incidentondersteuning, audit- en inspectierechten, beëindigingsrechten en transitieregelingen nodig. Een leverancier die deze verplichtingen niet kan ondersteunen, kan verhinderen dat de fabrikant een geloofwaardige belofte over de ondersteuningsperiode doet.

Crosswalk van beheersmaatregelen voor governance van ondersteuningsperioden die gereed is voor audits

Deze crosswalk laat beveiliging, Juridische Zaken, Product en Sales één taal spreken. Het register voor ondersteuningsperioden is niet alleen CRA-bewijs. Het is leveranciersassurance voor NIS2, derde-partijassurance voor DORA, ondersteuning voor beveiliging van de verwerking onder GDPR en een governanceartefact voor ISO 27001-certificering.

De privacy-invalshoek: wanneer niet-ondersteund onveilig wordt

Governance van beveiligingsondersteuningsperioden is niet alleen een cyberbeveiligingsvraagstuk. Als het product persoonsgegevens opslaat, verzendt of verwerkt, kan niet-ondersteunde software een privacyrisico worden.

GDPR is van toepassing op verwerking in het kader van een vestiging in de EU en kan ook van toepassing zijn op niet-EU-organisaties die goederen of diensten aanbieden aan personen in de EU of hun gedrag monitoren. GDPR definieert persoonsgegevens breed en behandelt een inbreuk in verband met persoonsgegevens als een beveiligingsinbreuk die leidt tot onopzettelijke of onrechtmatige vernietiging, verlies, wijziging, ongeoorloofde verstrekking van of toegang tot verwerkte persoonsgegevens.

Voor governance van ondersteuningsperioden moeten privacyteams weten welke productversies persoonlijk identificeerbare informatie (PII) verwerken, welke systemen nog worden ondersteund, en of kwetsbaarheden de vertrouwelijkheid, integriteit of beschikbaarheid van persoonsgegevens beïnvloeden.

Clarysec’s enterprise PII Security Access Control Policy PII Security Access Control Policy vereist:

“[Both] De systeemeigenaar / applicatie-eigenaar MOET ten minste elk kwartaal en na een wezenlijke technische wijziging de dekking van kwetsbaarheidsbeoordelingen voor systemen die PII verwerken in REG12 registreren.”

Bron: PII Security Access Control Policy, beveiligde configuratie en kwetsbaarhedenbeheer, clausule 4.7.4 PII Security Access Control Policy

Het enterprise Processor Subprocessor Third Party Privacy Management Policy Beleid voor privacybeheer van verwerkers, subverwerkers en derde partijen voegt voortdurende monitoring toe voor privacyrelaties met een hoog risico:

“[All] De Vendor / Procurement Owner MOET actieve hoog-risico verwerkersrelaties en subverwerkersrelaties elk kwartaal monitoren en andere actieve PII-verwerkersrelaties en subverwerkersrelaties jaarlijks toetsen aan due-diligencevoorwaarden, contractstatus, assurancestatus, openstaande kwesties en beoordelingsdatums in REG08.”

Bron: Processor Subprocessor Third Party Privacy Management Policy, voortdurende monitoring, ondersteuning, interface voor verstrekking en exit, clausule 4.5.1 Beleid voor privacybeheer van verwerkers, subverwerkers en derde partijen

Wanneer een kwetsbaarheid een incident wordt, vereist het enterprise PII Incident Breach Management Policy Beleid voor incidenten met persoonsgegevens en datalekbeheer een beoordeling van triggers over meerdere kaders:

“[Conditional] De Privacy Lead / PIMS Manager MOET toepasselijke wettelijke, sectorale, financiële-sector-, cyberbeveiligings-, contractuele, klant- en service-recipientrapportagetriggers voor elk incident met hoge impact met betrekking tot PII evalueren en de uitkomst van de toepasselijkheid in REG01, REG08 en REG10 registreren.”

Bron: PII Incident Breach Management Policy, classificatie en datalekbeoordeling, clausule 4.2.6 Beleid voor incidenten met persoonsgegevens en datalekbeheer

Dit is de praktische overlap tussen CRA-ondersteuningsverplichtingen, NIS2-incidentcommunicatie, DORA-afhandeling van ernstige ICT-incidenten en GDPR-verantwoordingsplicht voor datalekken.

Hoe auditors hetzelfde proces voor ondersteuningsperioden toetsen

Een sterk governanceproces voor ondersteuningsperioden moet verschillende auditstijlen kunnen doorstaan. Het bewijs verandert niet veel, maar het perspectief van de auditor wel.

NIST CSF 2.0 is nuttig als communicatielaag omdat de GOVERN Function wettelijke, regelgevende, contractuele en privacyverplichtingen, doelstellingen voor risicobeheer, risicobereidheid, rollen, beleid en toezicht omvat. De supply-chain outcomes bestrijken leveranciersstrategie, kritikaliteit, contracten, due diligence, monitoring, incidentcoördinatie en bepalingen voor het einde van de relatie.

COBIT- en ISACA-achtige auditors richten zich vaak op de governanceopzet: wie is eigenaar van het besluit, welk proces is gedefinieerd, welke metrieken tonen prestaties aan, hoe worden uitzonderingen goedgekeurd en hoe wordt voortdurende verbetering afgehandeld.

Clarysec’s enterprise Informatiebeveiligingsbeleid Informatiebeveiligingsbeleid vat het principe van auditeerbaarheid samen:

“Alle geïmplementeerde beheersmaatregelen moeten auditeerbaar zijn, worden ondersteund door gedocumenteerde procedures en door bewaard bewijsmateriaal van werking.”

Bron: Informatiebeveiligingsbeleid, Vereisten voor beleidsimplementatie, clausule 6.6.1 Informatiebeveiligingsbeleid

Dat is de zin waaraan elke beveiligingsondersteuningsperiode moet kunnen voldoen.

Ondersteuning verlengen, verkorten of beëindigen zonder schijnzekerheid te creëren

De moeilijkste governancemomenten doen zich niet voor bij productlancering. Zij ontstaan wanneer de werkelijkheid verandert.

Mogelijk moet u ondersteuning verlengen omdat gereguleerde klanten afhankelijk zijn van het product, migratie niet haalbaar is of een sectorklant contractuele continuïteitsbehoeften heeft. Mogelijk moet u ondersteuning verkorten of beperken omdat een leverancier beveiligingsonderhoud intrekt, een component onmogelijk te patchen wordt, een platform technische grenzen bereikt of de productarchitectuur een kwetsbaarheidsklasse niet veilig kan ondersteunen.

Een beheerste wijziging van de ondersteuningsperiode moet het volgende omvatten:

• Wijzigingstrigger, zoals end-of-life bij een leverancier, kritieke kwetsbaarheid, klantcontract of regelgevingswijziging
• Geraakte producten, versies, klanten en sectoren
• Impactanalyse voor persoonsgegevens en kritieke diensten
• Haalbaarheidsbeoordeling van leveranciers en componenten
• Risicobeoordeling en besluit over restrisico
• Bijgewerkt register voor ondersteuningsperioden
• Bijgewerkte klantkennisgeving en contractuele positie
• Bijgewerkte SoA-notities waar beheersmaatregelen of verplichtingen wijzigen
• Managementgoedkeuring en beoordelingsdatum

Het enterprise Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden is nuttig wanneer de wijziging door een kwetsbaarheid wordt gedreven:

“Voor alle bevestigde kwetsbaarheden moet een remediatie- of mitigatieplan worden ontwikkeld. Implementatie van de fix moet worden geprioriteerd op basis van ernst. Kritieke kwetsbaarheden moeten bijvoorbeeld waar haalbaar binnen 14 dagen worden verholpen of gemitigeerd, of eerder wanneer actieve exploitatie wordt vastgesteld, terwijl kwesties met een lagere ernst binnen een redelijke termijn moeten worden aangepakt.”

Bron: Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden, Implementatievereisten, clausule 6.6 Beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden

Als een volledige fix niet onmiddellijk kan worden geleverd, kunnen compenserende beheersmaatregelen, uitgeschakelde functionaliteit, verhoogde monitoring of klantgerichte configuratierichtlijnen tijdelijk aanvaardbaar zijn, maar het besluit moet worden gedocumenteerd en gecommuniceerd.

Praktische Clarysec-checklist voor gereedheid van ondersteuningsperioden

Gebruik deze checklist voordat u een verplichting voor een CRA-beveiligingsondersteuningsperiode publiceert of vernieuwt.

• Staat het product en de versie in het register voor ondersteuningsperioden?
• Is de einddatum van ondersteuning goedgekeurd door Product, Beveiliging en het verantwoordelijke management?
• Zijn wettelijke, regelgevende en contractuele drijfveren gemapt in het nalevingsregister?
• Is het risicoscenario voor de ondersteuningsperiode opgenomen in het risicoregister?
• Zijn beheersmaatregelen gemapt in de Verklaring van Toepasselijkheid, inclusief 5.31, 8.8 en 8.25 waar van toepassing?
• Zijn kritieke leveranciers en componenten gemapt in het register van leveranciersafhankelijkheden?
• Is er bewijs dat componenten tijdens de ondersteuningsperiode kunnen worden gepatcht of vervangen?
• Zijn verantwoordelijkheden voor kwetsbaarheidsintake, triage, remediatie en openbaarmaking gedefinieerd?
• Zijn SLA’s voor kritieke patches afgestemd op beleid en klantcontracten?
• Worden patchlogboeken, releaseregistraties en kwetsbaarheidsbesluiten bewaard?
• Worden systemen met persoonsgegevens gedekt door bewijs voor kwetsbaarheidsbeoordelingen waar PII wordt verwerkt?
• Zijn klantkennisgevingen, ondersteuningsverklaringen en contractuele voorwaarden consistent?
• Is er een proces om ondersteuning met risicogoedkeuring te verlengen, verkorten of beëindigen?
• Ontvangen directiebeoordelingen input over risico’s rond ondersteuningsperioden, leveranciers, kwetsbaarheden en incidenten?
• Kan bewijs binnen 48 uur worden geleverd voor een klantaudit of verzoek van een toezichthouder?

Het enterprise PIMS Monitoring Audit Improvement Policy PIMS-beleid voor monitoring, audit en verbetering versterkt de discipline voor directiebeoordelingen binnen privacyprogramma’s:

“[Both] Topmanagement MOET PIMS-non-conformiteiten, corrigerende maatregelen, monitoringresultaten, auditresultaten, privacyrisico’s, leveranciersassurance en wijzigingsinput van belanghebbenden in REG12 beoordelen tijdens elke directiebeoordeling.”

Bron: PIMS Monitoring Audit Improvement Policy, PIMS-directiebeoordeling, clausule 4.3.5 PIMS-beleid voor monitoring, audit en verbetering

Voor governance van beveiligingsondersteuningsperioden moet hetzelfde beoordelingsritme in het hele ISMS gelden: kwetsbaarheden, patchprestaties, leveranciersassurance, klantverplichtingen, incidenten, ondersteuningsuitzonderingen en corrigerende maatregelen moeten input leveren voor de directiebeoordeling.

Maak de beveiligingsondersteuningsperiode verdedigbaar

De EU Cyberweerbaarheidsverordening verandert de manier waarop organisaties naar productbeveiliging kijken. Zij dwingt fabrikanten en softwareaanbieders verder te denken dan de releasedag. De beveiligingsondersteuningsperiode wordt een levenscyclusbelofte die moet worden ontworpen, beheerst, gevolgd en aangetoond.

Voor CISO’s is de les duidelijk: laat de ondersteuningsperiode niet alleen in productmarketing staan. Voor compliancemanagers: bouw geen afzonderlijke CRA-bewijssilo. Voor auditors: toets of ondersteuningsverplichtingen traceerbaar zijn naar risico’s, beheersmaatregelen, leveranciers, incidenten en gedocumenteerde goedkeuringen. Voor bedrijfseigenaren: besef dat een geloofwaardige ondersteuningsperiode een marktvoordeel kan worden, vooral bij verkoop aan NIS2-gereguleerde sectoren, DORA-financiële entiteiten en privacygevoelige klanten.

Clarysec helpt organisaties dit operationeel te maken via:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint voor het opbouwen van ISMS-traceerbaarheid, gedocumenteerde informatie, SoA-mapping en gereedheid voor audits
• Zenith Controls: The Cross-Compliance Guide Zenith Controls voor het mappen van ISO/IEC 27002:2022-beheersmaatregelen aan NIS2, DORA, GDPR, NIST CSF 2.0 en auditverwachtingen
• Enterprise- en mkb-beleidspakketten voor kwetsbaarhedenbeheer, veilige ontwikkeling, wettelijke naleving, leveranciersafhankelijkheden, privacybewijs en incidentrespons
• Praktische registers en workflows voor bewijs die beloften over ondersteuningsperioden omzetten in auditeerbare governance

Uw volgende stap is eenvoudig: kies één vlaggenschipproductversie en bouw het bewijsdossier voor de beveiligingsondersteuningsperiode. Map de verplichting, keur de ondersteuningsperiode goed, test het kwetsbaarheidsproces, valideer leveranciersafhankelijkheden, bevestig klantcommunicatie en bewaar de registraties.

Als u één product kunt verdedigen, kunt u het model opschalen. Als u één product niet kunt verdedigen, is het hiaat geen documentatieprobleem. Het is governance.

Download de Zenith Blueprint, gebruik Zenith Controls om uw bewijs te mappen, of vraag een Clarysec-gereedheidsbeoordeling aan om CRA-beveiligingsondersteuningsperioden om te zetten in ISO 27001-governance die gereed is voor audits.