A software company that holds ISO 27001 and reads ISO 9001 for the first time recognises most of it. Context, leadership, planning, support, performance evaluation and improvement, clauses 4 to 7, 9 and 10, are the Harmonized Structure: the same skeleton with "quality" where the other standard says "information security". Then it reaches clause 8, Operation, and finds production, traceability, preservation of outputs and the property of customers, written for organisations that make and ship things. The temptation is to declare most of it not applicable. That is the wrong reading: clause 8 applies in full to software, it simply needs translating, and the translation is what this article does, sub-clause by sub-clause, in our reading of the text; ISO's wording is not reproduced. In our own clause register, clause 8 is where the honest gaps are, and the translation below is what those records would have to hold.

8.1 Operational planning and control

The clause asks the organisation to plan and control the processes that deliver its products and services: criteria for the processes and for acceptance, the resources, and enough documented information to have confidence the processes ran as planned. For software this is the definition of how a feature travels from request to production, and the acceptance criteria at each step. It is also the one place clause 8 mentions outsourced processes, which for a software company means the cloud platform it runs on.

8.2 Requirements for products and services

8.2.1 is customer communication: how a customer learns what the product does, how they order, how they complain, and how their property (data, in a software company's case) is handled. 8.2.2 is determining the requirements: what the product must do, including the statutory and regulatory requirements that apply to it. 8.2.3 is the review of those requirements before the organisation commits to supply, with the results retained, and it is the sub-clause software companies most often fail: a contract signed with a customer-specific commitment nobody in engineering reviewed is a nonconformity against 8.2.3 whatever the engineers later achieve. 8.2.4 is changes to requirements, which in a subscription product is every release note.

For a software company, "statutory and regulatory requirements" now has a specific content: from 11 December 2027 the essential requirements of Annex I of the Cyber Resilience Act are requirements for the product in the sense of 8.2.2, and a requirements review that does not consider them is incomplete.

8.3 Design and development

This is the software development life cycle, and the sub-clause that maps most directly. 8.3.2, planning, is the definition of the process: stages, reviews, verification and validation, responsibilities, what the customer is involved in, and the documented information to keep. 8.3.3, inputs, is the requirements a piece of work starts from, including statutory and regulatory ones and what was learned from previous products. 8.3.4, controls, is the distinction the standard draws that engineering teams usually blur: reviews (does the design meet the plan), verification (does the output meet the input requirements, which is code review and the test suite) and validation (does the product meet its intended use, which is acceptance by or on behalf of the user). 8.3.5, outputs, is what leaves development: the artefact, its documentation, the acceptance criteria it was checked against. 8.3.6, changes, is change control on the design, with the review, authorisation and any action to prevent adverse impact retained.

A company that keeps its work in a ticketing system, reviews code, runs tests and has a definition of done has most of the records 8.3 asks for. What it usually lacks is the record that ties them together per change: which input, which review, which verification, which validation, who authorised.

8.4 Externally provided processes, products and services

8.4.1 asks for external providers to be evaluated, selected, monitored and re-evaluated, with records; 8.4.2 for the type and extent of control to match how much the provider's output affects the product; 8.4.3 for the provider to be told what is required of it. For software the external providers are three kinds: the cloud platform and the SaaS tools the product runs on, which are outsourced processes under 8.4.1; the open-source and commercial components in the product, which are externally provided products; and contractors who write code. The second kind is where 8.4 and the Cyber Resilience Act meet: the due diligence Article 13(5) asks for on components is the 8.4.2 control for a software dependency, and the same record serves both.

8.5 Production and service provision

The sub-clause with the most to translate. 8.5.1, controlled conditions, is deployment: the documented process, the monitoring at the stages that matter, the infrastructure and environment, competent people, and validation of processes whose output cannot be verified afterwards, which in a software company is the deployment pipeline itself. 8.5.2, identification and traceability, is versions and build identifiers: which build is in production, which customer runs which version, and the ability to trace an output back through its history where traceability is required. 8.5.3, property belonging to customers or external providers, is the sub-clause a SaaS company must read most carefully: customer data, credentials and content are customer property in the standard's sense, to be identified, verified, protected and safeguarded, and a loss or damage reported to the customer with the record retained. 8.5.4, preservation, is backups and the integrity of the delivered artefact. 8.5.5, post-delivery activities, is support, maintenance and updates for as long as the organisation has committed to them, which under the Cyber Resilience Act becomes the support period with security updates for its length. 8.5.6, control of changes, is change control on production, with the review, the person authorising and any action retained.

8.6 Release of products and services

Release happens only when the planned arrangements have been completed, unless otherwise approved by a relevant authority and, where applicable, the customer; the record shows the evidence of conformity with the acceptance criteria and who authorised the release. For software this is the release gate: the criteria the build was checked against, the evidence, and the named person who let it go. A company that deploys continuously still has a release in the standard's sense at every deployment, and the gate is the pipeline's checks plus the approval that lets a change through; the record is the pipeline's log, provided it names the criteria and the approver.

8.7 Control of nonconforming outputs

An output that does not conform is identified and controlled so it is not delivered or used unintentionally: corrected, segregated, the customer informed, or a concession obtained; and the record says what the nonconformity was, what was done, any concession and who decided. For software, nonconforming outputs are the bugs that reached a customer, the incidents, the release that had to be withdrawn. The bug tracker holds most of the record already; what 8.7.2 adds is the decision, in particular the concession, which is the decision to ship or leave in place a known defect, by someone with the authority to make it. A known defect shipped without that decision is the nonconformity an auditor writes up, not the defect itself.

What this adds up to

Read this way, clause 8 for a software company is six records the company mostly already produces in its ticketing, code review, CI and incident tools, plus the decisions those tools do not record: the requirements review before a commitment, the authorisation of a design change, the release approval, and the concession on a known defect. The management system's job is to hold those decisions next to the artefacts, so that an auditor, or a customer's auditor, can follow one change from request to release with every check and every name in place. Which of clause 8's sub-clauses StandardOS holds records for, and which it does not, is published clause by clause; the other clauses, the documented information and the management review among them, are the ones an ISO 27001 company already runs.

Sources

  • ISO 9001:2015, clauses 8.1 to 8.7, cited by number; the text is ISO's and is not reproduced.
  • Regulation (EU) 2024/2847 (CRA), Article 13(5) and (8), Annex I, for where the same records are required of a software product.

This is not certification advice. How far a sub-clause applies to a given product is decided in the organisation's scope and justified there; the translation above is ours.