En softwarevirksomhed, der har ISO 27001 og læser ISO 9001 for første gang, genkender det meste. Kontekst, lederskab, planlægning, støtte, præstationsevaluering og forbedring, punkt 4 til 7, 9 og 10, er Harmonized Structure: det samme skelet med »kvalitet«, hvor den anden standard siger »informationssikkerhed«. Så når den punkt 8, Drift, og finder produktion, sporbarhed, bevaring af output og kundernes ejendom, skrevet til organisationer, der fremstiller og sender ting. Fristelsen er at erklære det meste af det ikke relevant. Det er den forkerte læsning: Punkt 8 gælder fuldt ud for software, det skal bare oversættes, og oversættelsen er det, denne artikel gør, underpunkt for underpunkt, i vores læsning af teksten; ISO's ordlyd gengives ikke. I vores eget punktregister er punkt 8 der, hvor de ærlige huller er, og oversættelsen nedenfor er det, de registreringer skulle indeholde.

8.1 Driftsplanlægning og -styring

Punktet beder organisationen planlægge og styre de processer, der leverer dens produkter og ydelser: kriterier for processerne og for accept, ressourcerne og tilstrækkelig dokumenteret information til at have tillid til, at processerne forløb som planlagt. For software er det definitionen af, hvordan en funktion rejser fra ønske til produktion, og acceptkriterierne ved hvert trin. Det er også det ene sted, punkt 8 nævner outsourcede processer, hvilket for en softwarevirksomhed betyder den cloudplatform, den kører på.

8.2 Krav til produkter og ydelser

8.2.1 er kundekommunikation: hvordan en kunde får at vide, hvad produktet gør, hvordan de bestiller, hvordan de klager, og hvordan deres ejendom (data, i en softwarevirksomheds tilfælde) håndteres. 8.2.2 er fastlæggelse af kravene: hvad produktet skal gøre, herunder de lov- og myndighedskrav, der gælder for det. 8.2.3 er gennemgangen af de krav, før organisationen forpligter sig til at levere, med resultaterne opbevaret, og det er det underpunkt, softwarevirksomheder oftest fejler: En kontrakt underskrevet med en kundespecifik forpligtelse, som ingen i udviklingen har gennemgået, er en afvigelse fra 8.2.3, uanset hvad udviklerne senere opnår. 8.2.4 er ændringer af krav, hvilket i et abonnementsprodukt er hver eneste release note.

For en softwarevirksomhed har »lov- og myndighedskrav« nu et konkret indhold: Fra den 11. december 2027 er de væsentlige krav i bilag I til Cyber Resilience Act krav til produktet i 8.2.2's forstand, og en kravgennemgang, der ikke tager dem i betragtning, er ufuldstændig.

8.3 Design og udvikling

Dette er softwareudviklingens livscyklus, og det underpunkt, der passer mest direkte. 8.3.2, planlægning, er definitionen af processen: trin, gennemgange, verifikation og validering, ansvar, hvad kunden er involveret i, og den dokumenterede information, der skal opbevares. 8.3.3, input, er de krav, et stykke arbejde tager udgangspunkt i, herunder lov- og myndighedskrav og det, der er lært af tidligere produkter. 8.3.4, styring, er den sondring, standarden drager, og som udviklingsteams normalt udvisker: gennemgange (opfylder designet planen), verifikation (opfylder outputtet inputkravene, hvilket er kodegennemgang og testsuiten) og validering (opfylder produktet sin tilsigtede brug, hvilket er accept af eller på vegne af brugeren). 8.3.5, output, er det, der forlader udviklingen: artefaktet, dets dokumentation, de acceptkriterier, det blev kontrolleret mod. 8.3.6, ændringer, er ændringsstyring af designet, med gennemgangen, autorisationen og enhver handling for at forebygge negativ indvirkning opbevaret.

En virksomhed, der holder sit arbejde i et ticketsystem, gennemgår kode, kører test og har en definition of done, har de fleste af de registreringer, 8.3 beder om. Det, den normalt mangler, er den registrering, der binder dem sammen pr. ændring: hvilket input, hvilken gennemgang, hvilken verifikation, hvilken validering, hvem der autoriserede.

8.4 Eksternt leverede processer, produkter og ydelser

8.4.1 beder om, at eksterne leverandører evalueres, udvælges, overvåges og evalueres på ny, med registreringer; 8.4.2 om, at styringens art og omfang svarer til, hvor meget leverandørens output påvirker produktet; 8.4.3 om, at leverandøren får at vide, hvad der kræves af den. For software er de eksterne leverandører af tre slags: den cloudplatform og de SaaS-værktøjer, produktet kører på, som er outsourcede processer efter 8.4.1; open source- og kommercielle komponenter i produktet, som er eksternt leverede produkter; og kontrahenter, der skriver kode. Den anden slags er der, hvor 8.4 og Cyber Resilience Act mødes: Den due diligence, artikel 13(5) beder om for komponenter, er 8.4.2-styringen for en softwareafhængighed, og den samme registrering tjener begge.

8.5 Produktion og levering af ydelser

Underpunktet med mest at oversætte. 8.5.1, styrede betingelser, er udrulning: den dokumenterede proces, overvågningen på de trin, der betyder noget, infrastrukturen og miljøet, kompetente mennesker og validering af processer, hvis output ikke kan verificeres bagefter, hvilket i en softwarevirksomhed er selve udrulningspipelinen. 8.5.2, identifikation og sporbarhed, er versioner og build-identifikatorer: hvilket build der er i produktion, hvilken kunde der kører hvilken version, og evnen til at spore et output tilbage gennem dets historie, hvor sporbarhed kræves. 8.5.3, ejendom tilhørende kunder eller eksterne leverandører, er det underpunkt, en SaaS-virksomhed skal læse mest omhyggeligt: Kundedata, loginoplysninger og indhold er kundens ejendom i standardens forstand, som skal identificeres, verificeres, beskyttes og sikres, og et tab eller en skade rapporteres til kunden med registreringen opbevaret. 8.5.4, bevaring, er backup og det leverede artefakts integritet. 8.5.5, aktiviteter efter levering, er support, vedligeholdelse og opdateringer, så længe organisationen har forpligtet sig til dem, hvilket under Cyber Resilience Act bliver supportperioden med sikkerhedsopdateringer i hele dens længde. 8.5.6, styring af ændringer, er ændringsstyring i produktion, med gennemgangen, den person, der autoriserer, og enhver handling opbevaret.

8.6 Frigivelse af produkter og ydelser

Frigivelse sker først, når de planlagte foranstaltninger er gennemført, medmindre en relevant myndighed og, hvor det er relevant, kunden godkender andet; registreringen viser beviset for overensstemmelse med acceptkriterierne, og hvem der autoriserede frigivelsen. For software er det frigivelsesporten: de kriterier, buildet blev kontrolleret mod, beviset og den navngivne person, der lod det gå. En virksomhed, der udruller løbende, har stadig en frigivelse i standardens forstand ved hver udrulning, og porten er pipelinens kontroller plus den godkendelse, der lader en ændring passere; registreringen er pipelinens log, forudsat at den nævner kriterierne og godkenderen.

8.7 Styring af afvigende output

Et output, der ikke er i overensstemmelse, identificeres og styres, så det ikke leveres eller bruges utilsigtet: korrigeret, adskilt, kunden informeret, eller en afvigelsestilladelse indhentet; og registreringen siger, hvad afvigelsen var, hvad der blev gjort, enhver afvigelsestilladelse, og hvem der besluttede. For software er afvigende output de fejl, der nåede en kunde, hændelserne, den udgivelse, der måtte trækkes tilbage. Fejlsporingssystemet indeholder allerede det meste af registreringen; det, 8.7.2 tilføjer, er beslutningen, især afvigelsestilladelsen, altså beslutningen om at sende eller lade en kendt fejl blive, truffet af en med bemyndigelse til det. En kendt fejl, der sendes uden den beslutning, er den afvigelse, en auditor skriver op, ikke fejlen selv.

Hvad det lægger sammen til

Læst sådan er punkt 8 for en softwarevirksomhed seks registreringer, som virksomheden for det meste allerede frembringer i sine ticket-, kodegennemgangs-, CI- og hændelsesværktøjer, plus de beslutninger, de værktøjer ikke registrerer: kravgennemgangen før en forpligtelse, autorisationen af en designændring, frigivelsesgodkendelsen og afvigelsestilladelsen for en kendt fejl. Ledelsessystemets opgave er at holde de beslutninger ved siden af artefakterne, så en auditor, eller en kundes auditor, kan følge én ændring fra ønske til frigivelse med hver kontrol og hvert navn på plads. Hvilke af punkt 8's underpunkter StandardOS har registreringer for, og hvilke det ikke har, er offentliggjort punkt for punkt; de øvrige punkter, den dokumenterede information og ledelsens evaluering blandt dem, er dem, en ISO 27001-virksomhed allerede kører.

Kilder

  • ISO 9001:2015, punkt 8.1 til 8.7, citeret ved nummer; teksten er ISO's og gengives ikke.
  • Forordning (EU) 2024/2847 (CRA), artikel 13(5) og (8), bilag I, for hvor de samme registreringer kræves af et softwareprodukt.

Dette er ikke certificeringsrådgivning. Hvor langt et underpunkt gælder for et givet produkt, afgøres i organisationens anvendelsesområde og begrundes der; oversættelsen ovenfor er vores.