Auditing a Software Company Quality Management System: Sprints, Releases and Defects

Why Software QMS Audits Are Different

Walk into a manufacturing plant and the audit trail is visible. You can see the production line, inspect the finished goods, check the calibration sticker on the gauge. Walk into a software company and the product is invisible. The process happens inside laptops, inside code repositories, inside ticketing systems. If you try to audit a software company the same way you audit a factory, you will miss almost everything that matters.

Software companies certified to ISO 9001 are more common than many auditors realise. SaaS businesses, custom development houses, embedded systems teams, and internal IT departments all operate under quality management systems. The challenge is that their processes use terminology and tooling that can be unfamiliar to auditors trained in traditional industries. Sprints, pull requests, staging environments, regression testing, defect severity ratings. These are not exotic concepts. They are the operational reality of how software is designed, built, tested, and released.

This article is written for internal auditors and lead auditors who are preparing to audit a software company QMS. It covers the key process areas to examine, the evidence to look for, and the nonconformities that appear most often in this sector. The guidance applies whether you are conducting an internal audit, a second party supplier audit, or preparing an organisation for certification.

Understanding the Software Development Process Before You Audit It

You do not need to be a developer to audit a software QMS effectively. You do need to understand the shape of the process well enough to follow the audit trail. Most software companies today use some form of Agile methodology, with Scrum being the most common. Some use Kanban, some use a hybrid, and a small number still operate under traditional waterfall approaches. Knowing which model applies changes how you trace evidence.

Agile and Scrum Basics for Auditors

In a Scrum environment, work is organised into sprints. A sprint is a fixed period, typically two weeks, during which the team commits to completing a defined set of work items called user stories or tasks. At the end of each sprint, the team holds a sprint review and a retrospective. These meetings are directly relevant to your audit because they are where quality issues surface and where improvement actions are supposed to be captured.

The sprint backlog is the list of work committed for the current sprint. The product backlog is the larger list of future work. User stories describe functionality from the perspective of the end user. Acceptance criteria define what done means for each story. These documents and records are your primary audit evidence for Clause 8.1 operational planning and control, and for Clause 8.3 design and development if applicable.

Waterfall and Hybrid Models

Some organisations, particularly those building safety critical or regulated software, still use stage gate processes. Requirements are documented upfront, design is reviewed before coding begins, testing is a distinct phase, and release requires formal sign off. This is easier to audit in some ways because the documentation structure is more familiar. The audit trail from requirement to release is linear and the approval records are explicit.

Hybrid models are common. An organisation might use Agile for feature development but maintain formal release management processes with documented approval gates before anything goes to production. When you encounter a hybrid, spend time in the opening meeting clarifying exactly how the process works before you start sampling evidence.

Clause 8.3 Design and Development: The Core of a Software Audit

For most software companies, Clause 8.3 is the heart of the QMS audit. This clause covers design and development planning, inputs, controls, outputs, changes, and transfers. Each element maps directly to software development activities.

Design and Development Planning

Ask to see how the organisation plans its development work. In an Agile environment, this might be sprint planning records, product roadmaps, or release plans. In a waterfall environment, it will be a project plan or systems development life cycle document. You are looking for evidence that the organisation has defined the stages of development, who is responsible at each stage, and what review and approval activities occur.

A common gap here is that organisations treat sprint planning as informal and leave no record that planning occurred. If a developer can tell you what they are working on but cannot show you where that work was formally accepted into a sprint, you have a potential nonconformity against Clause 8.3.1.

Design and Development Inputs

Requirements are the inputs to development. Ask how requirements are captured and where they live. In most software companies, requirements exist as user stories in a tool like Jira, Azure DevOps, or Trello. Some organisations maintain a separate requirements specification document. The key questions are: are the requirements documented, are they reviewed for completeness and clarity before development begins, and is there a record of that review?

Acceptance criteria attached to user stories are a practical form of requirement verification. If a story has no acceptance criteria, the team has no agreed definition of done. That is a quality risk and often a finding.

Design and Development Controls

Controls in software development include code reviews, automated testing, peer review of test cases, and static analysis. Ask to see evidence that these controls are applied consistently. Pull request records in GitHub or Bitbucket show who reviewed code before it was merged. Test run reports from automated test suites show whether tests were executed and what the results were.

One of the most common nonconformities in software QMS audits is that the organisation has a policy requiring code review but the evidence shows that code was merged without review. Always sample a selection of recent pull requests and check whether the review requirement was followed. When you find exceptions, ask why. Sometimes the answer reveals a systemic issue with resourcing or time pressure that management is not aware of.

Design and Development Outputs and Transfer

The output of development is a software build. The transfer is the release to a test environment, a staging environment, or production. Ask how releases are managed. Is there a release checklist? Who approves a release? What happens if the release fails? What is the rollback procedure?

Look for release notes or deployment records that document what was released, when, who approved it, and what testing was completed before release. Organisations that release frequently, sometimes multiple times per day in a continuous delivery model, need to show that their automated pipeline enforces the required quality checks before deployment. If the pipeline can be bypassed, ask whether that has ever happened and what controls exist to prevent unauthorised deployments.

Auditing Defect Management

Defects are nonconforming outputs in ISO 9001 terms. Clause 8.7 requires the organisation to control nonconforming outputs, which in software means identifying defects, recording them, assessing their impact, and deciding how to handle them. Most software companies use a bug tracking system for this. Jira is the most common, but there are many others.

What to Look for in the Defect Register

Ask to see the defect register or bug backlog. You are looking for evidence that defects are being recorded systematically, that they are classified by severity or priority, that someone is accountable for each defect, and that there is a process for deciding when a defect must be fixed before release versus when it can be deferred.

The severity classification is important. A defect that causes data loss is not the same as a cosmetic display issue. Ask how the organisation defines severity levels and whether those definitions are documented. Then sample a selection of defects and check whether the severity assigned matches the definition. Inconsistent classification is a common finding and is a symptom of inadequate process definition or training.

Escaped Defects and Production Incidents

Escaped defects are defects that make it through testing and are discovered by customers in production. These are the most significant quality failures in a software context. Ask how production incidents are recorded and investigated. Is there a post incident review process? Are the root causes documented? Are corrective actions tracked to completion?

This maps directly to Clause 10.2, nonconformity and corrective action. If the organisation is experiencing repeated escaped defects in the same functional area but cannot demonstrate that root cause analysis has been conducted and corrective actions implemented, that is a significant finding. It suggests the corrective action process is not effective.

Auditing Release Management and Change Control

Change control in software is the discipline of ensuring that changes to the system are planned, reviewed, tested, and approved before they are applied. This maps to Clause 8.5.6 in ISO 9001, control of changes. It also connects to Clause 6.3, planning of changes at the QMS level.

Ask how the organisation manages changes to production systems. Is there a change advisory board or equivalent approval process? Are emergency changes handled differently from planned changes? What testing is required before a change can be promoted to production?

In organisations with mature DevOps practices, change control is often embedded in the deployment pipeline. Automated tests must pass, a defined number of reviewers must approve the pull request, and deployment to production requires a specific trigger. This is a perfectly valid control approach. Your job is to verify that the controls are actually enforced and that the pipeline configuration is itself subject to change control.

Customer Requirements and Satisfaction

Software companies often have complex customer relationships. Some sell a product to many customers. Some build bespoke solutions for individual clients under contracts. Some operate internal IT departments with internal customers. The way you audit customer requirements and satisfaction depends on which model applies.

Contract Review and Requirements Traceability

For bespoke development, ask how customer requirements are captured and agreed before development begins. Is there a statement of work, a functional specification, or a requirements document that the customer has signed off? How are changes to requirements managed during the project? Is there a formal change request process?

Traceability from customer requirement to delivered feature is a quality indicator. If the organisation cannot show which user stories correspond to which contracted requirements, it cannot demonstrate that it has delivered what was agreed. That is a gap against Clause 8.2.

Customer Satisfaction Monitoring

Ask how the organisation monitors customer satisfaction. For product companies, this might include net promoter scores, support ticket analysis, churn rates, or customer review data. For bespoke development, it might include project closure reviews or client feedback surveys. The key is that the organisation is actually using this data to evaluate performance and drive improvement, not just collecting it.

For more on what auditors look for when reviewing customer satisfaction evidence, the article on understanding ISO 9001 customer satisfaction requirements provides a solid foundation.

Competence and Awareness in a Software Team

Clause 7.2 requires the organisation to determine the competence required for roles affecting quality. In a software company, this includes developers, testers, architects, product owners, and release managers. Ask how competence is defined for each role. Is there a competence matrix or role description that specifies required skills and experience?

Then ask how competence is evaluated. For technical roles, this might include technical assessments during hiring, peer review of code, or performance reviews that include quality indicators. Certification in specific technologies can be evidence of competence but is not the only valid form. The organisation needs to show that it has assessed competence, not just assumed it based on job title.

Training records are often incomplete in software companies. Developers attend conferences, complete online courses, and learn on the job, but these activities are rarely recorded in a way that satisfies Clause 7.2. Ask whether the organisation maintains records of training and development activities and whether those records are linked to the competence requirements for each role.

Internal Audit and Management Review in a Software Company

Many software companies treat their ISO 9001 internal audit as a compliance exercise rather than a genuine quality tool. The internal audits are conducted annually, the same checklist is used each time, and the findings are minor observations that are quickly closed without real investigation. This pattern is common and is itself a finding.

Ask to see the internal audit programme and the most recent internal audit reports. Check whether the audit scope reflects the risk profile of the organisation. If the organisation has had multiple escaped defects in the past year, the internal audit programme should reflect that risk. If it does not, ask why.

Management review is often conducted as a brief agenda item in a leadership meeting. Ask to see the management review records and check that all required inputs are addressed. In a software company, relevant inputs include defect trends, customer complaint data, sprint velocity and quality metrics, release success rates, and the results of internal audits. If the management review record shows only a high level summary without any data, it is unlikely to be driving genuine improvement.

For practical guidance on conducting internal audits from start to finish, the article on how to do an internal audit from start to finish covers the full process in a way that applies across industries including software.

Common Nonconformities in Software QMS Audits

Based on audit experience across software companies of different sizes and models, the following nonconformities appear most frequently.

• No documented acceptance criteria for user stories, meaning the definition of done is informal and inconsistent across the team.
• Code merged without the required peer review, contrary to the documented development procedure.
• Defects not classified consistently, making it impossible to determine whether severity thresholds for release hold are being applied.
• No post incident review for escaped defects, or reviews conducted but findings not actioned.
• Release approval records missing, particularly for hotfix releases made under time pressure.
• Competence records not maintained for developers and testers, with no documented assessment of required versus actual competence.
• Internal audit programme not risk based, with the same scope and frequency applied regardless of quality performance.
• Management review inputs incomplete, particularly the absence of customer satisfaction data and analysis and evaluation results.

If you want to understand how to write up findings from these situations in a way that will actually drive corrective action, the article on how to write a nonconformity report is worth reading before your audit.

Practical Tips for Auditing a Software Company

A few practical points that make a real difference when auditing in this environment.

Request a process walkthrough before you start sampling. Ask someone from the development team to walk you through a recent feature from backlog to production. This gives you the full picture of how the process actually works, not just how it is documented. It also builds rapport and helps you ask better questions when you start examining evidence.

Learn the tooling before the audit. If the organisation uses Jira, spend thirty minutes familiarising yourself with how Jira works before the audit day. You do not need to be an expert, but you need to be able to navigate the system well enough to follow the audit trail without relying entirely on the auditee to show you what you are looking for.

Ask for exports and screenshots rather than live demonstrations. Live demonstrations of software systems can be manipulated, intentionally or not. Asking for exported reports or screenshots that you can keep as working papers is better audit practice and creates a more reliable evidence record.

Follow the audit trail from defect to corrective action. Pick a significant defect from the past six months and trace it from initial report through investigation, root cause analysis, corrective action, and verification of effectiveness. This single trail will tell you more about the maturity of the QMS than any checklist.

Do not be intimidated by technical language. If a developer uses a term you do not understand, ask them to explain it. Curiosity is an auditor strength, not a weakness. Most developers are happy to explain their work to someone who is genuinely interested.

Preparing for a Software Company Audit

If you are a quality manager preparing your software company for an internal or certification audit, the preparation process is similar to any ISO 9001 audit but with some specific focus areas.

Make sure your documented procedures reflect how development actually happens, not how it was originally planned. Many software companies have procedures written two or three years ago that no longer match current practice. Auditors will identify the gap between documented process and actual practice quickly, so it is better to update the documentation before the audit than to explain the discrepancy during it.

Ensure your defect management records are complete and that severity classifications are consistently applied. Pull a sample of your own records before the audit and check them against your documented criteria. If you find inconsistencies, address them and document the corrective action.

Prepare your team for interview. Developers and testers are often unfamiliar with ISO audit processes and may be nervous about being interviewed. A brief internal briefing explaining what the auditor is looking for and how to answer questions honestly and specifically will help the audit run more smoothly. The article on how to prepare your team for an internal audit has practical guidance for exactly this situation.

Building Auditor Competence for Software Sector Audits

Auditing software companies effectively requires a combination of ISO 9001 auditing competence and sector specific knowledge. If you are an experienced auditor from manufacturing or construction, the sector knowledge gap is real and worth addressing before you take on a software audit assignment.

Reading about Agile methodologies, DevOps practices, and software testing approaches will give you enough context to audit competently. You do not need to become a developer. You need to understand the process well enough to follow the audit trail, ask the right questions, and recognise when something does not add up.

If you are building your auditing skills more broadly, Audit Workshop offers ISO 9001 internal auditor and lead auditor training that covers the audit process in depth, with practical exercises that develop the evidence gathering and questioning skills that make the difference in sector specific audits like software. The training is delivered by practitioners with real audit experience across a range of industries, which means the examples and scenarios used in training reflect the kind of situations you will actually encounter.