ISO 9001 and ISO 27001: Why They Matter for Software Development Firms

ISO 9001 and ISO 27001 do two different jobs and are often confused. ISO 9001 asks whether you can consistently deliver what you promised; ISO 27001 asks whether the information you hold is safe. For a software firm, the first is about repeatability and the second is about trust. Neither certificate proves your software is good — they prove you have a system for producing it and protecting it, and that an independent auditor checked. That distinction is the whole value, and also the whole limitation.

---

---

Two standards, two different questions

The most common mistake is treating these as interchangeable badges. They answer different questions.

ISO 9001 asks: can you consistently deliver what you promised? It is a quality management system standard that helps you capture requirements clearly, plan and control work, manage defects and complaints, oversee suppliers, and regularly review and improve your processes. It applies to any organisation of any size in any sector.

ISO/IEC 27001 asks: is the information you hold safe? It is an information security management system standard, and its subject is risk — identifying what information you hold, what could go wrong with it, and what controls you apply in response. The controls sit in Annex A, and you select from them based on your own risk assessment rather than implementing all of them by default.

A software firm can hold one without the other, and plenty do. Holding both signals something specific: that you have a repeatable delivery process and a governed approach to the data that process touches. For anyone building software that handles other people’s sensitive information, that combination is the point.

---

What ISO 9001 actually requires of a software firm

The standard is deliberately sector-agnostic, which means it reads abstractly until you translate it. For a development firm, the substance lands in seven places.

Context and interested parties. You have to identify who your work affects and what they need from it — clients, regulators, users, and in healthcare, patients who never signed your contract.

Leadership and quality policy. Someone senior owns quality, in writing, with defined responsibilities rather than an implied culture.

Risk and opportunity. Risk-based thinking runs through the 2015 edition. For software this means thinking about what could cause you to deliver the wrong thing, late, or broken — dependency risk, key-person risk, requirements drift.

Requirements control.You document the client’s needs as clear specifications, agree and record any changes, and verify that the final delivery matches the approved requirements. Scope creep is a quality management failure before it is a commercial one.

Design and development control. Planning, inputs, controls, outputs, changes. In software this maps onto your development lifecycle — code review, version control, release process, environment management.

Nonconformity and corrective action. What happens when something is wrong. Not just fixing the bug: recording it, finding the cause, and preventing recurrence. This is the clause that most improves a young firm, because it converts firefighting into a feedback loop.

Internal audit and management review. You check yourself on a schedule, and leadership formally reviews the results.

None of that is exotic. Most competent teams do a version of it already. What certification changes is that it becomes documented, consistent and evidenced — which is precisely what an enterprise buyer’s due diligence questionnaire asks for.

The revision arriving now

ISO 9001:2015, including its 2024 climate amendment, remains the current published edition. But ISO 9001:2026 has reached Final Draft International Standard stage and received final approval in July 2026, with publication expected in September 2026.

The changes are evolutionary rather than structural. The most notable addition is an explicit emphasis on quality culture and ethical behaviour within the leadership clause. Clause 6.1 now separates risk management and opportunity management into distinct sub-clauses, while the context clause explicitly incorporates climate change considerations. Analysts reviewing the draft describe the core requirements in clauses 4 to 10 as changing only slightly, with most additions in the non-mandatory guidance sections.

Two things matter for anyone certifying now. ISO 9001:2015 remains the only certifiable edition until the new one publishes, so there is no option to certify early against the 2026 text. After publication, certification bodies must complete the required training and accreditation steps before they can issue certificates against the new edition, so only a small number of ISO 9001:2026 certificates are likely to appear in the first few months.

The transition is expected to last roughly three years, so organisations certified to ISO 9001:2015 will have time to move to the new edition. The International Accreditation Forum will set the formal transition arrangements, so organisations should confirm the exact requirements and timeline with their certification body.

One thing the revision notably does not do: it introduces no specific requirements for artificial intelligence, digital transformation or automation, despite those appearing in the user survey that fed the revision. If you are looking for a quality standard that addresses AI systems directly, ISO 9001 is not it.

---

What ISO 27001 actually requires

ISO/IEC 27001:2022, with Amendment 1:2024, is the current and only valid edition. Under IAF mandatory document MD 26, the transition window from the 2013 revision closed on 31 October 2025, and organisations that missed that deadline must start the process from the beginning.

The standard has two halves.

The management system clauses mirror ISO 9001’s structure — context, leadership, planning, support, operation, evaluation, improvement — applied to information security. The core requirement is a documented risk assessment and risk treatment process. You identify information assets and threats, assess risk, decide treatment, and justify your decisions in a Statement of Applicability.

Annex A contains the controls. The 2022 edition restructured these substantially: 93 controls across four themes — organisational, people, physical and technological — replacing 114 controls across 14 domains. Eleven controls were new, addressing threat intelligence, information security for cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering and secure coding.

Several of those matter disproportionately to a development firm. Secure coding is now an explicit control. So is configuration management, and information security for use of cloud services — which for most software companies is where the actual risk lives.

The 2024 amendment is narrow: a requirement in clause 4.1 to determine whether climate change is a relevant issue, and a note in clause 4.2 that interested parties may have climate-related requirements. It adds no new Annex A controls.

Certification is granted following a two-stage audit by an accredited certification body, and the certificate runs for three years with annual surveillance audits in between. It is not a one-off exercise.

---

Why buyers ask for these, specifically

Certification is rarely bought for its own sake. It gets bought because someone else requires it, and understanding who and why tells you whether it is worth the cost.

Enterprise procurement uses it as a filter. Security questionnaires are expensive to answer individually. A certificate accredited by a recognised body compresses a large part of that exercise, and increasingly appears as a hard requirement rather than a preference in RFP documents.

Regulated sectors treat it as baseline hygiene. In healthcare, finance and government, organisations must assess suppliers that lack a governed information security framework from the ground up, which increases due-diligence effort and risk.

It aligns with other frameworks you may already face. ISO 27001 maps usefully onto SOC 2, GDPR accountability obligations, NIS2 and DORA. The work is not duplicated across each one.

Adoption has grown substantially. ISO Survey 2024 records 96,709 valid ISO/IEC 27001 certificates covering 179,877 sites, against 36,362 certificates in the 2019 survey — roughly 2.7 times over five years.

One caveat belongs with any year-on-year comparison, and it is the kind of thing vendors quoting this figure tend to leave out. The 2024 edition was the first compiled from the International Accreditation Forum’s CertSearch database rather than from voluntary certification-body reporting, so part of the apparent jump against 2023 reflects improved data coverage rather than new certifications. Germany is also understated in the 2024 figures because its accreditation body’s dataset was missing. The five-year trend is real. The single-year change is partly an artefact of how the data was gathered.

Either way, the direction is clear enough: when a control becomes common, its absence starts to look like a deficiency rather than a neutral choice.

For NHS suppliers specifically, be precise about what it does

This is where the marketing around ISO 27001 most often overstates its case, and where we have seen founders lose time.

ISO 27001 reduces your DSPT audit scope. It does not replace the DSPT. If you hold ISO 27001 or Cyber Essentials Plus, an independent DSPT audit covers only the evidence items those certifications do not already address. You still have to complete the Data Security and Protection Toolkit itself.

It is not a substitute for Cyber Essentials Plus. These are separate certifications with separate requirements, and NHS procurement expects both where applicable.

Under DTAC, ISO 27001 is supporting evidence rather than a pass. The Digital Technology Assessment Criteria — updated to version 2 and live from 6 April 2026 — assesses clinical safety, data protection, technical security, interoperability and usability. ISO 27001 contributes to the data protection and technical security sections. It contributes nothing to the clinical safety section, which requires DCB0129 evidence: a named Clinical Safety Officer, a Clinical Safety Case Report and a Hazard Log.

Scope is the thing that gets suppliers caught. If you cite ISO 27001 as evidence, the certificate’s scope must genuinely cover the systems that process NHS data — not a head-office administrative function. An assessor will read the scope statement on the certificate, and a mismatch between what is certified and what actually handles the data is a straightforward rejection.

---

What certification does not prove

Being honest about the limits is what makes the claim credible when you do make it.

It does not prove your software is secure. ISO 27001 certifies a management system. It does not test your application. A certified organisation can ship a vulnerable product, and a penetration test remains a separate and necessary exercise.

It does not prove your software is good. ISO 9001 certifies that you follow your own documented process consistently. If the process is poorly designed, you can be certified and still deliver weak work — consistently.

It does not transfer to your suppliers. Your certificate covers your organisation within its stated scope. The security posture of the APIs, models and infrastructure you build on is a separate assessment.

It does not satisfy regulatory obligations that attach to your product. If your software has a medical purpose, device classification, clinical risk management and — depending on market — regulatory approval apply independently. No management system certificate exempts you from those.

And it does not survive neglect. Certificates run three years with annual surveillance. An organisation that treats the audit as an event rather than a system drifts, and surveillance audits are designed to catch exactly that.

Certification shows that an organisation has built a management system around a recognised standard and that an independent auditor has assessed it. That provides useful assurance, but it does not guarantee the quality or security of the software itself. Procurement teams still need to examine how the organisation applies those controls in practice.

---

ISO certification is only one part of responsible software delivery

ISO 9001 and ISO 27001 create structure around quality and information security, but they do not replace disciplined engineering. For healthcare software, teams still need clear requirements, secure development practices, testing, review and appropriate regulatory controls throughout the build.

Related: Why we would not vibe code a clinical product — a practical look at where AI-assisted development helps and where stronger engineering controls are still necessary.

---

Why we are going through it

We are currently in the certification process for both standards. Two reasons, and neither is that we expected the certificate itself to win work.

The first is that the NHS and enterprise buyers we work with ask. Not always as a hard requirement, but as an early question in the due diligence conversation, and answering “no, but here is our informal process” costs more time than it saves.

The second is more useful, and slightly unexpected. Preparing for the audits forced us to write down things that existed only as habit — how a client requirement becomes a specification, who reviews what before release, what happens when a defect reaches production, which systems hold what data and who can reach them. Some of that documentation confirmed we were already doing the right thing. Some of it exposed that we were doing the right thing inconsistently, which is a different problem and a harder one to see from the inside.

That is the argument we would make to another software firm weighing the cost. The certificate is the visible output. The forced articulation of your own process is the part that changes how you work, and you get that whether or not the certificate ever wins you a contract.

---

A practical sequence for a small software firm

Nine steps, ordered so nothing blocks anything after it.

• Decide the scope precisely. Which legal entity, which sites, which services, which systems. Everything downstream depends on this, and an overly narrow scope is the most common reason a certificate fails to satisfy a buyer.
• Choose an accredited certification body. Accredited by UKAS in the UK, ANAB in the US, JAS-ANZ in Australia and New Zealand, or another IAF signatory. A non-accredited certificate costs less and is frequently rejected in procurement.
• Run a gap analysis against the current editions before you write anything new. Most firms already satisfy more clauses than they expect.
• Write the mandatory documentation. For ISO 27001 that includes the risk assessment methodology, the risk treatment plan and the Statement of Applicability. For ISO 9001, the quality policy, objectives and documented processes.
• Implement, then run the system long enough to generate records. Auditors assess evidence of operation, not intentions. A system with no history is not auditable.
• Complete an internal audit and a management review. Both are mandatory clauses and both are commonly left until too late.
• Stage 1 audit — a documentation and readiness review, which identifies what will fail before it fails.
• Stage 2 audit — the certification audit proper, assessing whether the system operates as documented.
• Plan for surveillance. Annual audits, and a three-year recertification cycle. Budget for it as an ongoing cost rather than a project.

The step most often underestimated is the fifth. A management system needs to have been running for long enough to have produced records — incidents handled, changes controlled, reviews minuted. There is no way to compress that, and attempting to is the most reliable way to fail Stage 2.

---

Where this leaves software firms

The case for certification is not that the badge sells software. It rarely does. The case is that both standards force you to make explicit what most teams hold implicitly, and implicit process is what breaks when a team grows, a key person leaves, or a client asks a question you have never had to answer in writing.

For a firm handling other people’s sensitive data, there is a second argument. The buyer cannot inspect your engineering culture. They can inspect a certificate, an audited scope statement and a surveillance history. In the absence of a long track record, that is one of the few credible signals available — which is precisely why buyers ask for it and why the scope statement matters more than the logo.

What certification will not do is substitute for the work. It sits alongside penetration testing, secure development practice, regulatory compliance where your product has a regulated purpose, and the ordinary discipline of building software carefully. Firms that treat it as the destination end up with a certificate and a problem. Firms that treat it as a framework tend to find that the process was worth more than the paperwork.

---

Frequently asked questions

What is the difference between ISO 9001 and ISO 27001?

ISO 9001 is a quality management system standard — it governs how you consistently deliver what you promised, covering requirements control, process management, defect handling and improvement. ISO/IEC 27001 is an information security management system standard — it governs how you identify information risks and apply controls against them. They share a common structure but answer different questions.

What are the current versions of ISO 9001 and ISO 27001?

ISO 9001:2015, including Amendment 1:2024 which added a climate change consideration, remains the current published edition. ISO/IEC 27001:2022, also with a 2024 climate amendment, is the current and only valid edition of the information security standard.

Is ISO 9001 being updated?

Yes. ISO 9001:2026 reached Final Draft International Standard stage and received final approval in July 2026, with publication expected in September 2026. ISO 9001:2015 remains the only certifiable edition until then. The changes are evolutionary — a new emphasis on quality culture and ethical behaviour in the leadership clause, and integration of the climate consideration. A transition period of roughly three years is expected.

Is ISO 27001:2013 still valid?

No. The transition period ended on 31 October 2025. Certificates issued against the 2013 edition are no longer valid, and organisations that did not transition must begin the certification process again.

How many Annex A controls does ISO 27001:2022 have?

93, organised into four themes — organisational, people, physical and technological. This replaced the previous structure of 114 controls across 14 domains. Eleven controls were new, including threat intelligence, information security for cloud services, configuration management, data masking, data leakage prevention, web filtering and secure coding.

Does ISO 27001 mean my software is secure?

No. ISO 27001 certifies an information security management system, not a product. It does not test your application, and it is not a substitute for penetration testing or secure development practice. A certified organisation can still ship vulnerable software.

Does ISO 9001 mean my software is high quality?

No. ISO 9001 certifies that you follow your own documented processes consistently and review them for improvement. If those processes are poorly designed, certification confirms consistency rather than quality.

Does ISO 27001 replace the NHS Data Security and Protection Toolkit?

No. Holding ISO 27001 reduces the scope of an independent DSPT audit, covering only evidence items the certification does not already address. It does not substitute for completing the DSPT, and it is not a substitute for Cyber Essentials Plus.

Is ISO 27001 enough to pass DTAC?

No. DTAC assesses clinical safety, data protection, technical security, interoperability and usability. ISO 27001 contributes to the data protection and technical security sections as supporting evidence. It contributes nothing to clinical safety, which requires DCB0129 evidence including a named Clinical Safety Officer, a Clinical Safety Case Report and a Hazard Log.

Does the scope of my certificate matter?

Considerably. If you cite ISO 27001 as evidence in a procurement, the certificate’s scope must cover the systems that actually process the buyer’s data. A certificate scoped to a head-office function while client data is processed elsewhere will not satisfy an assessor.

What is the difference between accredited and non-accredited certification?

An accredited certificate comes from a certification body that a recognised national accreditation body has assessed for competence, such as UKAS in the UK, ANAB in the US, or JAS-ANZ in Australia and New Zealand. Enterprise and public-sector buyers may reject non-accredited certificates because they provide less independent assurance.

How long does ISO certification last?

The certificate runs for three years, with annual surveillance audits in the intervening years and a full recertification audit at the end of the cycle. It is an ongoing commitment rather than a one-off exercise.

Can we say we are ISO certified while the audit is in progress?

 No. Until a certification body issues the certificate, claiming certification is a false statement. Accurate alternatives are that you are going through the certification process, or that your management systems are being assessed against the standards. Note also that organisations are certified while certification bodies are accredited — describing yourself as “ISO accredited” is incorrect and is quickly noticed.

Does ISO 9001 or ISO 27001 cover artificial intelligence?

Not specifically. The ISO 9001:2026 revision was expected by some to introduce requirements for AI and digital transformation, and the draft does not do so. ISO 27001 addresses information security controls that apply to AI systems as they would to any system, but neither standard is an AI management standard.

Do these certifications replace medical device regulation?

No. If your software has a medical purpose, classification and regulatory obligations apply independently of any management system certification. Device requirements in the UK, US and Australia are determined by intended purpose, not by which quality standards you hold.

---

About the author

Prashant Sithta is COO and Co-founder of KastHunt Consulting LLP, an AI-native healthcare technology firm serving clinics, healthtech founders and health systems across the UK, US and Australia.

As Chief Operating Officer, he focuses on operations and delivery governance, helping structure how healthcare AI and software projects move from requirements through implementation, review and delivery.

He writes about operational discipline, delivery systems, process governance and the practical controls required to build and scale healthcare technology responsibly.

Status note: KastHunt is currently going through certification to ISO 9001 and ISO/IEC 27001. This article will be updated when the process completes.

Questions or corrections: info@kasthunt.com

---

---