Een softwarebedrijf dat ISO 27001 heeft en ISO 9001 voor het eerst leest, herkent het meeste. Context, leiderschap, planning, ondersteuning, evaluatie van prestaties en verbetering, de paragrafen 4 tot en met 7, 9 en 10, zijn de Harmonized Structure: hetzelfde skelet met "kwaliteit" waar de andere norm "informatiebeveiliging" zegt. Dan komt het bij paragraaf 8, Uitvoering, en vindt productie, traceerbaarheid, behoud van outputs en het eigendom van klanten, geschreven voor organisaties die dingen maken en verzenden. De verleiding is om het meeste ervan niet van toepassing te verklaren. Dat is de verkeerde lezing: paragraaf 8 geldt volledig voor software, hij moet alleen worden vertaald, en die vertaling is wat dit artikel doet, subparagraaf voor subparagraaf, in onze lezing van de tekst; de bewoording van ISO wordt niet weergegeven. In ons eigen paragrafenregister is paragraaf 8 waar de eerlijke hiaten zitten, en de vertaling hieronder is wat die registraties zouden moeten bevatten.

8.1 Operationele planning en beheersing

De paragraaf vraagt de organisatie de processen te plannen en te beheersen die haar producten en diensten leveren: criteria voor de processen en voor de acceptatie, de middelen, en genoeg gedocumenteerde informatie om erop te kunnen vertrouwen dat de processen zijn verlopen zoals gepland. Voor software is dat de definitie van hoe een functie van aanvraag naar productie gaat, en de acceptatiecriteria bij elke stap. Het is ook de ene plaats waar paragraaf 8 uitbestede processen noemt, wat voor een softwarebedrijf het cloudplatform is waarop het draait.

8.2 Eisen voor producten en diensten

8.2.1 is communicatie met de klant: hoe een klant leert wat het product doet, hoe hij bestelt, hoe hij klaagt, en hoe zijn eigendom (gegevens, in het geval van een softwarebedrijf) wordt behandeld. 8.2.2 is het bepalen van de eisen: wat het product moet doen, inclusief de wettelijke en regelgevende eisen die erop van toepassing zijn. 8.2.3 is de beoordeling van die eisen voordat de organisatie zich tot levering verbindt, met de resultaten bewaard, en het is de subparagraaf waarop softwarebedrijven het vaakst falen: een contract dat is getekend met een klantspecifieke toezegging die niemand in engineering heeft beoordeeld, is een afwijking ten opzichte van 8.2.3, wat de engineers later ook bereiken. 8.2.4 is wijzigingen in eisen, wat in een abonnementsproduct elke release note is.

Voor een softwarebedrijf hebben "wettelijke en regelgevende eisen" nu een specifieke inhoud: vanaf 11 december 2027 zijn de essentiële eisen van bijlage I van de Cyber Resilience Act eisen voor het product in de zin van 8.2.2, en een beoordeling van eisen die ze niet in overweging neemt, is onvolledig.

8.3 Ontwerp en ontwikkeling

Dit is de softwareontwikkelcyclus, en de subparagraaf die het meest rechtstreeks overeenkomt. 8.3.2, planning, is de definitie van het proces: fasen, beoordelingen, verificatie en validatie, verantwoordelijkheden, waar de klant bij betrokken is, en de te bewaren gedocumenteerde informatie. 8.3.3, inputs, zijn de eisen waarvan een stuk werk vertrekt, inclusief wettelijke en regelgevende, en wat van eerdere producten is geleerd. 8.3.4, beheersmaatregelen, is het onderscheid dat de norm maakt en dat engineeringteams meestal vervagen: beoordelingen (voldoet het ontwerp aan het plan), verificatie (voldoet de output aan de inputeisen, oftewel codereview en de testsuite) en validatie (voldoet het product aan het beoogde gebruik, oftewel acceptatie door of namens de gebruiker). 8.3.5, outputs, is wat de ontwikkeling verlaat: het artefact, zijn documentatie, de acceptatiecriteria waartegen het is gecontroleerd. 8.3.6, wijzigingen, is wijzigingsbeheersing op het ontwerp, met de beoordeling, de autorisatie en elke maatregel om nadelige gevolgen te voorkomen, bewaard.

Een bedrijf dat zijn werk in een ticketsysteem bijhoudt, code beoordeelt, tests draait en een definition of done heeft, heeft de meeste registraties die 8.3 vraagt. Wat het meestal mist, is de registratie die ze per wijziging aan elkaar knoopt: welke input, welke beoordeling, welke verificatie, welke validatie, wie autoriseerde.

8.4 Extern geleverde processen, producten en diensten

8.4.1 vraagt dat externe aanbieders worden geëvalueerd, geselecteerd, gemonitord en opnieuw geëvalueerd, met registraties; 8.4.2 dat de aard en omvang van de beheersing overeenkomen met hoeveel de output van de aanbieder het product beïnvloedt; 8.4.3 dat de aanbieder te horen krijgt wat van hem wordt verlangd. Voor software zijn de externe aanbieders van drie soorten: het cloudplatform en de SaaS-tools waarop het product draait, uitbestede processen onder 8.4.1; de open-source en commerciële componenten in het product, extern geleverde producten; en contractanten die code schrijven. De tweede soort is waar 8.4 en de Cyber Resilience Act elkaar ontmoeten: de zorgvuldigheid die artikel 13(5) voor componenten vraagt is de 8.4.2-beheersing voor een softwareafhankelijkheid, en dezelfde registratie dient beide.

8.5 Productie en dienstverlening

De subparagraaf met het meeste om te vertalen. 8.5.1, beheerste omstandigheden, is de uitrol: het gedocumenteerde proces, de monitoring op de fasen die ertoe doen, de infrastructuur en omgeving, competente mensen, en validatie van processen waarvan de output achteraf niet te verifiëren is, wat in een softwarebedrijf de uitrolpipeline zelf is. 8.5.2, identificatie en traceerbaarheid, zijn versies en build-identificaties: welke build in productie staat, welke klant welke versie draait, en het vermogen om een output door zijn geschiedenis terug te traceren waar traceerbaarheid vereist is. 8.5.3, eigendom van klanten of externe aanbieders, is de subparagraaf die een SaaS-bedrijf het zorgvuldigst moet lezen: klantgegevens, inloggegevens en content zijn klanteigendom in de zin van de norm, te identificeren, te verifiëren, te beschermen en te beveiligen, en verlies of beschadiging wordt aan de klant gemeld met de registratie bewaard. 8.5.4, behoud, is back-ups en de integriteit van het geleverde artefact. 8.5.5, activiteiten na levering, is ondersteuning, onderhoud en updates zolang de organisatie zich daartoe heeft verbonden, wat onder de Cyber Resilience Act de ondersteuningsperiode wordt, met beveiligingsupdates voor de hele duur. 8.5.6, beheersing van wijzigingen, is wijzigingsbeheersing in productie, met de beoordeling, de autoriserende persoon en elke maatregel bewaard.

8.6 Vrijgave van producten en diensten

Vrijgave gebeurt pas wanneer de geplande regelingen zijn afgerond, tenzij een bevoegde autoriteit en, indien van toepassing, de klant anders goedkeuren; de registratie toont het bewijs van conformiteit met de acceptatiecriteria en wie de vrijgave autoriseerde. Voor software is dit de vrijgavepoort: de criteria waartegen de build is gecontroleerd, het bewijs, en de benoemde persoon die hem liet gaan. Een bedrijf dat continu uitrolt, heeft bij elke uitrol nog steeds een vrijgave in de zin van de norm, en de poort is de controles van de pipeline plus de goedkeuring die een wijziging doorlaat; de registratie is het logboek van de pipeline, mits het de criteria en de goedkeurder noemt.

8.7 Beheersing van afwijkende outputs

Een output die niet conform is, wordt geïdentificeerd en beheerst zodat hij niet onbedoeld wordt geleverd of gebruikt: gecorrigeerd, afgezonderd, de klant geïnformeerd, of een concessie verkregen; en de registratie zegt wat de afwijking was, wat is gedaan, elke concessie en wie besliste. Voor software zijn afwijkende outputs de bugs die een klant hebben bereikt, de incidenten, de release die moest worden teruggetrokken. De bugtracker bevat het grootste deel van de registratie al; wat 8.7.2 toevoegt, is de beslissing, in het bijzonder de concessie, dat wil zeggen de beslissing om een bekend defect te leveren of te laten staan, door iemand met de bevoegdheid daartoe. Een bekend defect dat zonder die beslissing wordt geleverd, is de afwijking die een auditor opschrijft, niet het defect zelf.

Wat dit bij elkaar oplevert

Zo gelezen is paragraaf 8 voor een softwarebedrijf zes registraties die het bedrijf grotendeels al produceert in zijn ticket-, codereview-, CI- en incidenttools, plus de beslissingen die die tools niet vastleggen: de beoordeling van eisen vóór een toezegging, de autorisatie van een ontwerpwijziging, de vrijgavegoedkeuring en de concessie voor een bekend defect. De taak van het managementsysteem is die beslissingen naast de artefacten te houden, zodat een auditor, of de auditor van een klant, één wijziging van aanvraag tot vrijgave kan volgen met elke controle en elke naam op zijn plaats. Voor welke subparagrafen van paragraaf 8 StandardOS registraties bijhoudt, en welke niet, is paragraaf voor paragraaf gepubliceerd; de overige paragrafen, de gedocumenteerde informatie en de directiebeoordeling daaronder, zijn de paragrafen die een ISO 27001-bedrijf al voert.

Bronnen

  • ISO 9001:2015, paragrafen 8.1 tot en met 8.7, aangehaald op nummer; de tekst is die van ISO en wordt niet weergegeven.
  • Verordening (EU) 2024/2847 (CRA), artikel 13(5) en (8), bijlage I, voor waar dezelfde registraties van een softwareproduct worden vereist.

Dit is geen certificatieadvies. Hoe ver een subparagraaf op een bepaald product van toepassing is, wordt in het toepassingsgebied van de organisatie beslist en daar gemotiveerd; de vertaling hierboven is de onze.