ISO/IEC 29110: ISO/IEC 29110 – Tutorial (about 60 minutes)

ISO/IEC 29110 is a family of international standards and guides that gives very small entities – companies, departments or projects of up to 25 people – a slimmed-down, ready-to-use version of the big systems and software life cycle standards. Start-ups, small software houses, in-house development teams and small systems integrators use it to bring order to how they plan, build, test and deliver work, and to prove that discipline to customers. After this tutorial you will be able to explain how the series is organised, choose the right profile for a small organisation, describe the two processes of the Basic profile in detail, and plan a realistic path from informal habits to a certified, repeatable way of working.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: ISO/IEC 29110 is not one document but a multi-part series developed by ISO/IEC JTC 1/SC 7 (Software and systems engineering), Working Group 24, so there is no single "edition". The core documents current on the ISO catalogue are: ISO/IEC 29110-1-1:2024 (Overview) and ISO/IEC 29110-1-2:2024 (Vocabulary), International Standards that together replaced the withdrawn Technical Report ISO/IEC TR 29110-1:2016; ISO/IEC 29110-2-1:2015 (Framework and taxonomy) with Amendment 1:2022; ISO/IEC TR 29110-3-1:2020 (process assessment guidelines); ISO/IEC 29110-3-2:2018 (conformity certification scheme), confirmed in 2024, with Amendment 1:2025, which removes the requirement for recertification every three years; ISO/IEC 29110-3-3:2016 (certification requirements for bodies that use process assessment); ISO/IEC 29110-4-1:2018 (software engineering profile specifications for the generic profile group), confirmed in 2024; and ISO/IEC 29110-5-1-1:2025 and ISO/IEC 29110-5-1-2:2025, the first International Standard editions of the software Entry and Basic profile guidelines, which replaced the 2011 Technical Reports. ISO/IEC 29110-5-4:2025 adds agile software development guidelines. The software guidelines for the Intermediate and Advanced profiles were still Technical Reports (2017 and 2018) at the time of writing and are being converted into International Standards, so check the ISO catalogue for their current status; guidelines for systems engineering (the 5-6-x parts) and for service delivery also exist. This tutorial follows the 2025 Basic profile guidelines and notes where older Technical Reports are still the current text. Verified 2026-10-29 against the ISO catalogue entries for each part.

Who it is for: developers, team leads, project managers, founders of small software or systems companies, quality people in small engineering teams, and the purchasing or supplier-quality staff of larger organisations who buy from small suppliers and want to understand what an ISO/IEC 29110 certificate means.

Prerequisites: none. Some experience of working on a software or systems project helps, but every term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why the series exists, what a very small entity is, and where the series deliberately stops (for example at safety-critical work).
You will be able to describe the parts of the series and the difference between a profile specification and a guideline.
You will be able to choose between the Entry, Basic, Intermediate and Advanced profiles for a given organisation.
You will be able to walk through the Project Management and Software Implementation processes of the Basic profile, with their roles and work products.
You will be able to outline self-assessment, process assessment and conformity certification, and say what a certificate does and does not prove.
You will be able to plan an adoption in a small team, using deployment packages and existing tools.
You will be able to position the series against ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288, ISO 9001, CMMI and safety standards.

Lesson 1 – Origins, purpose and scope

Why very small entities needed their own standards

Most of the world's businesses are small. Many of the people who write software, design electronic boards or integrate systems for larger customers work in companies with a handful of employees, or in a small department inside a bigger organisation. These small groups are often highly skilled, but they rarely have a quality department, a process group or the budget to hire consultants. When they look at the classic life cycle standards – ISO/IEC/IEEE 12207 for software life cycle processes and ISO/IEC/IEEE 15288 for system life cycle processes – they find documents written for organisations of every size, with dozens of processes and the expectation that the user will tailor them. Tailoring a general standard well is itself expert work.

The result, observed in surveys carried out before the series was written, was that small organisations either ignored standards entirely or tried to adopt them and gave up. That had a business cost: customers, especially large companies and public bodies, increasingly asked suppliers to show evidence of a disciplined way of working, and small suppliers had no affordable way to provide it. They were shut out of some contracts not because their work was poor, but because they could not demonstrate that it was good.

Who wrote it and how

To close this gap, the international committee responsible for software and systems engineering standards, ISO/IEC JTC 1/SC 7, set up a working group dedicated to very small entities, Working Group 24, in the mid-2000s. The group brought together national experts, researchers and practitioners, and drew on national process models that some countries had already built for their small software companies. The first documents of the series appeared in 2011. Since then the series has grown to cover systems engineering as well as software, more profiles, assessment and certification, and the early Technical Reports have gradually been turned into full International Standards.

The working group's central idea is the profile: instead of asking a small team to tailor a large standard, experts do the tailoring once, carefully, and publish the result. A profile selects a small subset of processes, activities, tasks and outcomes from the parent standards – 12207 for software, 15288 for systems, and ISO/IEC/IEEE 15289 for the content of documentation – and arranges them for a typical small-entity situation. The small team can then adopt the profile as it is.

Scope and deliberate limits

The series defines a very small entity (VSE) as an enterprise, an organisation such as a government agency or a non-profit, a department, or a project with up to 25 people. The number is a guide to the intended audience, not a gate: larger organisations are explicitly allowed to use the processes, and a small project inside a multinational can be treated as a VSE. The series also states that it is meant for teams that lack experience in tailoring 12207 or 15288; a team that already tailors those standards competently is encouraged to keep using them.

Three further limits matter in practice. First, the series is life cycle neutral: the processes can be carried out in a waterfall, iterative, incremental, evolutionary or agile style. The guidelines describe what must happen and what must be produced, not the order of meetings or the length of a sprint. Second, the profiles of the generic profile group – the main set of profiles described in this tutorial – are aimed at organisations that do not develop critical software or systems. The 2025 Basic profile guidelines say so explicitly. Third, the Basic profile assumes one product built by one work team; organisations running several projects in parallel need a higher profile.

Why it appears next to safety-critical engineering

You may meet ISO/IEC 29110 in catalogues of safety-critical or automotive engineering standards, as in this course catalogue. The reason is practical: many small suppliers in those supply chains need a first, affordable step towards disciplined engineering before they can tackle domain standards such as IEC 61508, ISO 26262 or Automotive SPICE. It is important to be precise about this. The generic profiles give a foundation – planned projects, controlled requirements, traceability, verification, configuration management – but they do not contain the hazard analysis, safety integrity levels, independence of assessment or safety case that a safety standard demands. A small company writing safety-related firmware must apply the relevant safety standard; ISO/IEC 29110 can make that easier, but it is not a substitute. The series' architecture leaves room for specific profile groups for particular domains, which would be documented in their own parts, but the generic profiles are not safety standards.

Lesson 2 – Key concepts and vocabulary

The series has a compact vocabulary, much of it inherited from 12207 and 15288. Learn these terms first; the rest of the tutorial uses them constantly.

Very small entity (VSE) – an enterprise, organisation, department or project with up to 25 people; the intended user of the series.
Profile – a pre-tailored subset of processes, activities, tasks, outcomes and work products, selected from base standards for a defined kind of VSE.
Profile group – a set of related profiles that share a purpose and can be climbed step by step. The generic profile group has four: Entry, Basic, Intermediate and Advanced.
Profile specification – the normative document (Part 4) that states what an organisation must implement to conform to a profile; it is what certification audits check.
Guidelines – the explanatory documents (Part 5) that describe, task by task, how a VSE can implement a profile, with roles, inputs, outputs and tool suggestions.
Process – a set of related activities that transforms inputs into outputs to achieve a stated purpose; the Basic profile has two, Project Management (PM) and Software Implementation (SI).
Activity – a cohesive group of tasks within a process, such as project planning or software construction; activities are numbered, for example PM.1 or SI.4.
Task – a single required or recommended action within an activity, assigned to one or more roles, with named input and output work products.
Process objective – a result the process must achieve (numbered PM.O1, SI.O1 and so on); each activity contributes to one or more objectives, and they trace back to outcomes of the base standards.
Work product – anything produced or used by a task: a plan, a requirement list, a test report, the code itself. The guidelines describe each work product's purpose and expected content.
Role – a set of responsibilities, such as Customer, Project Manager, Technical Leader or Work Team. One person can hold several roles, and one role can be shared by several people.
Statement of Work – the customer's description of the work to be done: the product, the scope, deliverables, constraints and schedule expectations. It is the starting input of project planning.
Software Configuration – the consistent, versioned set of everything delivered or needed to maintain the software: requirements, design, code, tests, user and maintenance documentation.
Project Repository – the controlled store, with backups, where the project's work products and their versions are kept.
Traceability record – links between requirements, design elements, code components and test cases, so that every requirement can be followed to its tests and back.
Verification and validation – verification checks that a work product is complete and correct against its inputs and criteria ("built right"); validation checks that it meets the customer's real needs ("right thing built").
Deployment package – a free, practical kit (process description, templates, checklists, examples, tool hints, mapping to the standard) that helps a VSE implement one part of a profile at a time.
Conformity certification – a third-party audit that confirms an organisation has implemented the processes of a profile specification; it certifies processes, not products.

Two distinctions in this list cause most confusion for newcomers. The first is between the profile specification and the guidelines. The specification is short and normative: it lists what must be in place. The guidelines are long and practical: they show one good way to put it in place. An auditor checks against the specification; a team learns from the guidelines. The second is between verification and validation, which the Basic profile weaves into almost every activity rather than leaving to the end. A requirements review with the customer is validation; a peer check of a design against the requirements is verification.

Notice also what the vocabulary does not contain: there are no maturity levels, no capability scores and no management system clauses. A VSE either implements a profile or it does not yet. Progress is shown by moving from one profile to the next, which you will see in Lesson 3.

Lesson 3 – Structure of the series

The parts and their audiences

The series is arranged by audience. Each part answers the question "who needs to read this, and for what?" The numbering uses a main part number, then sub-numbers for the domain (for example 1 for software, 6 for systems engineering in Part 5) and the profile (1 Entry, 2 Basic, 3 Intermediate, 4 Advanced). So ISO/IEC 29110-5-1-2 reads as "Part 5 guidelines, software, Basic profile".

Figure 1 – The parts of the ISO/IEC 29110 series grouped by what readers use them for: understanding the series, implementing a profile, or checking conformity.

Part	What it contains	Main readers
Part 1 (1-1 Overview, 1-2 Vocabulary)	Concepts, the characteristics and needs of VSEs, the reasons for profiles, the catalogue (taxonomy) of profiles, and the common vocabulary	VSEs, their customers, assessors, standards writers
Part 2 (2-1 Framework and taxonomy)	The logic for defining profiles and the elements common to all of them: structure, conformity and assessment; guidance for domain-specific profiles	Profile producers, tool and method vendors
Part 3 (3-1, 3-2, 3-3 …)	Process assessment guidelines, the conformity certification scheme, and requirements for certification bodies that use process assessment	Auditors, assessors, certification and accreditation bodies, VSEs preparing for audit
Part 4 (4-1 software; further 4-m parts for other domains)	Normative profile specifications, for example ISO/IEC 29110-4-1 for the software profiles of the generic profile group	VSEs, customers, auditors
Part 5 (5-1-x software, 5-6-x systems, 5-4 agile, service delivery)	Management and engineering guidelines: processes, activities, tasks, roles, work products and tools for each profile	VSEs and their customers

A useful rule of thumb: a small company that simply wants to work better reads Part 5 for its chosen profile and keeps Part 4 nearby. Parts 1 and 2 matter mostly to people writing new profiles, and Part 3 matters once the company wants an external audit.

The four profiles of the generic profile group

The generic profile group is meant for the large majority of VSEs that do not develop critical products. Its four profiles form a roadmap: each one builds on the one below, so an organisation can start where it is and grow.

Figure 2 – The four profiles of the generic profile group form a roadmap; each profile builds on the previous one as the entity grows.

Entry suits start-ups (the guidelines speak of entities that began operating less than three years ago) and small projects of roughly six person-months of effort or less. It keeps the two core processes but with fewer tasks and work products.
Basic describes the development of a single application by a single team under an internal or external agreement. It is the most widely documented profile and a common target for certification.
Intermediate is for VSEs that run more than one project in parallel with more than one team. It adds management across projects, so that staff, priorities and schedules are coordinated between parallel projects instead of being negotiated ad hoc.
Advanced is for VSEs that want to sustain and grow as independent, competitive businesses, adding business-level practices on top of the Intermediate profile.

The same four-step idea exists for systems engineering (the 5-6-x guidelines, based on 15288, for VSEs that develop systems made of hardware and software), and the series also offers guidance for service delivery. In this tutorial we concentrate on the software profiles, because they are the most widely used and the best way to understand the whole series.

Inside the Basic profile guidelines

The 2025 Basic profile guidelines follow a regular layout that is worth knowing, because every other guideline in the series looks similar. After scope, terms and the conventions used in diagrams, an overview states the entry conditions for using the profile – essentially, a defined customer agreement, usually expressed in a Statement of Work. Then come the two processes. For each, the guidelines state its purpose, its objectives (outcomes), the roles involved, and the activities broken into tasks. Each task names its role, its input work products and its output work products. Finally, separate clauses describe every role and every work product, and suggest kinds of software tools.

The 2025 edition also adds informative annexes that a VSE may switch on when it needs them: a support process for maintaining the software after delivery, extra testing tasks (with an additional role and work products), accessibility tasks, security-related tasks and work products, and a description of the deployment packages. Another change from the 2011 Technical Report is the replacement of "optional" tasks with conditional tasks, which apply when a customer has asked for a particular work product, such as an operation guide. That small change removed a frequent argument about what an "optional" item meant during audits.

Lesson 4 – How it works in practice

The two processes and how they connect

The Basic profile is easiest to understand as two processes passing work products back and forth. Project Management (PM) plans and controls the project and deals with the customer. Software Implementation (SI) turns the agreed requirements into a working, tested, documented product. The plan flows from PM to SI; the software configuration and change requests flow back from SI to PM, and from PM to the customer.

Figure 3 – Information flow in the Basic profile: Project Management plans and controls, Software Implementation produces the Software Configuration, and closure ends in customer acceptance.

Project Management activities

PM.1 Project planning. The Project Manager reviews the Statement of Work with the customer, then builds the Project Plan: the tasks needed to produce the deliverables, their estimated duration and effort, the work team and its roles, the schedule, the cost estimate, the identified risks, the version control strategy, the delivery instructions and the description of the product and its scope. The plan is verified, then reviewed and accepted by the customer, and the Project Repository is set up according to the version control strategy. Planning is not a one-time event: in an iterative project the plan is refined each iteration, but there must always be a current, agreed plan.

PM.2 Project plan execution. While the work runs, the Project Manager monitors progress against the plan and records it in progress status records. Change requests – from the customer or from the team – are analysed for their effect on cost, schedule and technical content and accepted or rejected with the customer. Regular review meetings are held with the work team and with the customer, with agreements and actions recorded in meeting records and tracked to closure. The repository is backed up as the strategy demands, and recovered from backup when needed.

PM.3 Project assessment and control. The Project Manager evaluates actual progress, cost, effort and risks against the plan, decides on corrective actions for deviations, records them in a correction register and follows them up. Where the evaluation reveals that requirements must change, a change request is raised and goes back through PM.2.

PM.4 Project closure. The finished deliverables are handed over according to the delivery instructions, the customer's acceptance is formalised in an acceptance record, and the repository is updated so that the final configuration is preserved for maintenance or later projects.

Software Implementation activities

SI.1 Initiation. The team reviews the current Project Plan with the Project Manager so everyone understands the scope and their tasks, and the Technical Leader sets up or updates the implementation environment – tools, repositories, build and test set-up.

SI.2 Software requirements analysis. The Analyst elicits and documents the requirements, including interface and user documentation needs, and verifies them for clarity, correctness and testability. The customer validates them, so that both parties agree on what will be built. The agreed requirements are placed under version control and a traceability record is started.

SI.3 Software architectural and detailed design. The Designer produces the architecture and detailed design – components, interfaces, data – and the test cases and test procedures are defined from the requirements. Design and tests are verified, and the traceability record is extended from requirements to design and tests.

SI.4 Software construction. Programmers build and unit-test the components according to the design, correct defects, and update traceability from design to code components.

SI.5 Software integration and tests. The components are integrated and the integrated software is tested with the agreed test cases and procedures. Results go into a test report; defects are corrected and retested. The product operation guide and the user documentation are prepared or updated and verified – where the customer requires them, which is where conditional tasks come in.

SI.6 Product delivery. The maintenance documentation is prepared and verified, the full Software Configuration is assembled and checked for consistency, and it is handed to Project Management for delivery to the customer.

Roles

The Basic profile uses a small set of roles: the Customer (who defines needs and accepts results), the Project Manager, the Technical Leader, the Work Team as a whole, and, within Software Implementation, the more specialised Analyst, Designer and Programmer roles. In a five-person company one founder may be Project Manager and Technical Leader at once, and every developer may be Analyst, Designer and Programmer at different moments. What matters is that each task has someone responsible, and that verification tasks are done by someone able to judge the work objectively – ideally not only the author.

Working agile with the Basic profile

Because the profile is life cycle neutral, an agile team does not need to abandon its practices. A common mapping looks like this: PM.1 happens at the start of a release and is refreshed in each iteration plan; PM.2 and PM.3 are carried out through daily stand-ups, iteration reviews and retrospectives, as long as progress, decisions and corrective actions are recorded somewhere durable; SI.2 to SI.5 happen inside every iteration for the stories selected; SI.6 and PM.4 happen at each release. The backlog can serve as the requirements record if it is versioned and agreed with the customer; links between stories, commits and automated tests can serve as the traceability record. The test is simple: could an auditor, or a new team member, see what was agreed, what was done, what was checked and what changed? Teams that want more detail can use ISO/IEC 29110-5-4:2025, which gives guidelines for strengthening agile software development with the practices of the series.

Implementation steps for a small team

Pick the profile. One product and one team usually means Basic; a start-up with tiny projects may begin with Entry.
Do a gap analysis. Compare current habits with each activity and task. Most teams find they already do much of SI.4 and SI.5 but have weak planning records, informal requirements and no traceability.
Use deployment packages. Packages exist for topics such as project management, requirements, version control, verification and validation, and product delivery. Adopt one or two at a time rather than everything at once.
Fit the work products into existing tools. A plan can be a page in the wiki; change requests can be tickets; the repository can be the version control system plus a document folder with backups.
Pilot on one real project and adjust templates based on what the team actually used.
Review and improve. After the pilot, check the gap analysis again, then decide whether to seek an external assessment or certification.

Lesson 5 – Assessment, certification and compliance

Three ways to check conformity

Part 3 of the series separates three kinds of checking, and they serve different purposes.

Self-assessment for improvement. The VSE checks its own processes against a profile, usually with checklists derived from the guidelines, to find gaps and plan improvements. This costs little and is where almost every adoption begins.
Process assessment. The process assessment guidelines (ISO/IEC TR 29110-3-1:2020) describe how to assess the processes of a VSE against a profile in a way compatible with ISO/IEC 33002, the requirements for process assessment in the ISO/IEC 33000 family. They support two uses: an organisation that wants its implemented processes assessed for conformance to a profile, and a customer that asks a third party to assess a supplier.
Conformity certification. ISO/IEC 29110-3-2:2018 defines a certification scheme: rules under which an independent certification body audits a VSE and certifies that it has implemented the processes of a profile specification from Part 4. ISO/IEC 29110-3-3:2016 adds requirements for certification bodies that base their conformity assessment on process assessments and maturity models, a topic the 3-2 scheme leaves out of its own scope.

What a certificate is – and is not

An ISO/IEC 29110 certificate is a process certification. It is not a management system certificate like ISO 9001 and it is not a product certificate. It tells a customer that, at the time of the audit, the VSE had implemented the processes of a named profile – for example the software Basic profile – and could show evidence of them in its project work. It does not state that a particular product is fit for purpose, secure or safe, and the certification scheme says this plainly. There is no numeric score or maturity level on the certificate; the result is conformity to a named profile.

Figure 4 – A typical path from self-assessment to conformity certification for a VSE, including the loop for correcting nonconformities.

How an audit works in practice

The auditor uses the profile specification as the yardstick. Because the processes are project-based, the evidence comes from real projects: the Statement of Work and its review, the Project Plan and its acceptance, progress and meeting records, change requests and their handling, requirements, designs and test cases with their traceability, test reports, verification and validation results, the delivered configuration and the acceptance record. Interviews with the people holding the roles confirm that the records reflect how work really happens. Nonconformities must be corrected before the certificate is issued.

How long a certificate stays valid and what surveillance applies is set by the certification scheme and the certification body. Since Amendment 1 of 2025, ISO/IEC 29110-3-2 no longer requires recertification every three years; check the current rules of the body you work with rather than assuming a fixed cycle. Certification bodies themselves are accredited or peer-assessed, and the certification scheme is written primarily as the criteria document for that purpose.

Who uses certificates

Customers – large companies, public agencies and integrators – can use a certificate as evidence that a small supplier works in a disciplined way, which lowers their supplier-selection effort. Several national governments and industry associations, in Latin America and South-East Asia for example, have supported training, coaching and certification of small software companies as part of industry development programmes. For the VSE itself, the main benefit is usually not the certificate but the shared, repeatable way of working that it forces the team to build.

Remember the compliance boundary from Lesson 1. A certificate for the generic Basic profile says nothing about compliance with a safety standard, a data protection law or a security certification scheme. Those need their own evidence and, where required, their own assessments.

Lesson 6 – Worked example

The organisation

Brightline Software is a 14-person company. It builds and maintains web and mobile applications for regional transport and logistics firms: route planning portals, depot scheduling tools, driver apps. It has a director who also sells, one project manager, two technical leads, nine developers and one tester. Work arrives as fixed-scope contracts or as yearly change budgets. Recently a large logistics group asked bidders for "evidence of a recognised software process" and Brightline lost the bid. The director decides to adopt ISO/IEC 29110.

Step 1 – Choose the profile

Brightline usually runs two or three projects at the same time with two teams, which strictly points towards the Intermediate profile. The director and the project manager decide, sensibly, to begin with the Basic profile on one team and one project, because the gaps are at project level: no written plans, requirements scattered across emails, no traceability. Once the Basic practices are routine on all projects, they will look at Intermediate for cross-project management. They also note one exception: a prospective customer has asked about a controller for an automated depot gate. That would involve machine safety, so it falls outside the generic profiles and would need the relevant safety standards; Brightline decides not to take on that work for now.

Step 2 – Self-assessment

The project manager walks through each PM and SI task with the team and marks it done, partly done or not done. The result: SI.4 construction and SI.5 testing are mostly done (code reviews, unit tests, a test environment); SI.2 is weak (requirements are agreed in meetings but not recorded or validated); there is no traceability; PM.1 produces a schedule but no risk list, no version control strategy and no customer-accepted plan; change requests are handled by phone; there are no meeting records; and closure is "we deployed it". Backups exist for code but not for documents.

Step 3 – Deployment packages and tools

Instead of writing a process manual, the team adopts the deployment packages for project management, requirements, version control and verification and validation, and maps every work product to a tool they already have:

Basic profile work product	Where Brightline keeps it
Statement of Work, Project Plan	Wiki page per project, versioned, plan approval recorded as a signed-off comment from the customer
Requirements specification	Epics and user stories in the issue tracker with acceptance criteria; a frozen export at each agreed baseline
Change requests	A dedicated ticket type with impact fields (effort, schedule, cost) and a customer decision
Traceability record	Story IDs in commit messages and in automated test names; a report generated per release
Meeting and progress records	Short notes from iteration reviews and weekly customer calls, with action items as tickets
Project Repository and backup	Git hosting plus a project document space, both backed up nightly; a restore test each quarter
Acceptance record	Customer acceptance form attached to the release ticket

Step 4 – Pilot project

The pilot is a depot scheduling portal for a mid-sized haulier, planned as five two-week iterations. In PM.1 the project manager reviews the customer's Statement of Work in a workshop, which reveals two vague items ("integration with our systems", "reports as needed"); both are clarified in writing before planning continues. The plan lists the work, estimates, team roles, a risk list (the haulier's legacy database is poorly documented), the branching and tagging strategy, and delivery instructions. The customer accepts the plan in writing.

In SI.2 the analyst turns the agreed scope into stories with acceptance criteria, the tester checks them for testability, and the customer's operations lead validates them in a review meeting. During iteration three the haulier asks for an extra drivers' rest-time report. Instead of slipping it in, the project manager raises a change request, estimates its effect – four extra days – and the customer accepts a revised end date. This is PM.2 in action, and the change is visible in the plan, the backlog and the traceability report.

In iteration four, PM.3 shows effort running 15 % over estimate because of the legacy database. The corrective action – a short spike with the customer's database administrator – is recorded in the correction register and closed a week later. SI.5 produces a test report per iteration; the final integration test finds two defects that are fixed and retested. Because the customer asked for an operation guide in the contract, the conditional task to produce one applies and the guide is verified by the tech lead. SI.6 assembles the full configuration – code, requirements baseline, test cases, test report, user guide, operation guide and maintenance notes – and PM.4 closes with a signed acceptance record and an updated repository.

Step 5 – Review and audit

After the pilot the team repeats the self-assessment. Most tasks are now done; the remaining weakness is that design verification is informal. They add a short design checklist to merge reviews. Over the next three months the practices spread to the second team, and Brightline invites a certification body to audit against the software Basic profile. The auditor samples two projects, interviews the project manager, a tech lead and two developers, and raises one minor nonconformity: on one project the customer's validation of a requirements change was not recorded. Brightline corrects it with evidence, receives its certificate, and in the next tender includes both the certificate and a description of its process.

What the example shows

The work products did not require new tools or heavy documents; they required making existing work visible, agreed and traceable. The biggest improvements came from three tasks the team had skipped: a reviewed Statement of Work, customer validation of requirements, and formal change handling. And the decision to stay away from the safety-related gate controller shows a mature understanding of the profile's limits.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 29110 sits on top of the large life cycle standards and alongside several assessment and quality frameworks. Understanding the neighbours helps you explain to a customer what the series is and is not.

Standard or framework	Focus	Relationship to ISO/IEC 29110
ISO/IEC/IEEE 12207	Software life cycle processes for organisations of any size	The source of the software profiles: PM and SI select and simplify 12207 process elements from a single-project point of view
ISO/IEC/IEEE 15288	System life cycle processes	The source of the systems engineering profiles (5-6-x) for VSEs that develop systems with hardware and software
ISO/IEC/IEEE 15289	Content of life cycle information items (documentation)	The source for the content of the profile work products
ISO/IEC 33000 family	Process assessment	The process assessment guidelines in Part 3 are designed to be compatible with it
ISO 9001	Quality management system for any organisation, certifiable	Different scope: 29110 certifies engineering processes, ISO 9001 a management system; a VSE can use 29110 practices as part of its ISO 9001 operation
CMMI	Capability and maturity model with appraisals, mostly used by larger organisations	Covers similar project and engineering practices with far more scope and cost; 29110 is the lighter, VSE-sized route
Automotive SPICE	Process assessment model for automotive suppliers	A small automotive supplier may use 29110 practices as a foundation, but carmakers assess against Automotive SPICE, not 29110
IEC 61508, ISO 26262, DO-178C	Functional safety and safety-critical software	Outside the generic profiles' scope; they require hazard analysis, integrity levels and independence that 29110 does not provide

Two relationships deserve a closer look. First, 12207 and 15288: the series does not compete with them. If your organisation grows and gains the expertise to tailor 12207 or 15288 itself, the series encourages you to do so; the profiles are a ramp, not a ceiling. The objectives of each profile process trace back to outcomes of the base standards, which makes the step up smoother.

Second, ISO 9001. Customers sometimes ask "is 29110 the same as ISO 9001 for software?" It is not. ISO 9001 requires a quality management system – policy, objectives, risk-based thinking, internal audit, management review, improvement – for any kind of organisation, and leaves the engineering method to the organisation. ISO/IEC 29110 says nothing about a management system but is specific about how software or systems projects are planned, built, verified and delivered. A small company can hold both, and the 29110 work products then become part of the evidence that its software service is under control.

Common pitfalls and best practices

Common pitfalls

Treating it as paperwork. Writing documents to satisfy an auditor, separate from the real work, doubles effort and still fails interviews. The records should be the working tools of the project.
Choosing the wrong profile. Claiming the Basic profile while running many parallel projects hides cross-project problems; jumping straight to Intermediate before project basics work leads to frustration.
Using it for critical products. Presenting a generic profile certificate as evidence of safety or security for a critical system misleads customers and may break contractual or legal obligations.
Skipping customer validation. Teams often verify requirements internally but never get the customer to confirm them, which is exactly where costly misunderstandings arise.
Informal change handling. Accepting changes by phone or chat without impact analysis destroys the plan's credibility and leaves no evidence trail.
Forgetting backups and restores. Code is usually backed up; documents and project records often are not, and restores are rarely tested.
Confusing certificate with quality. A certificate confirms processes at the time of audit; it does not guarantee each product is defect-free.

Best practices

Start with a self-assessment on a real project, not with writing a process manual.
Adopt deployment packages one at a time and adapt their templates to your existing tools.
Keep work products light but real: a one-page plan that is accepted and kept current beats a thirty-page plan nobody reads.
Automate traceability with story or requirement identifiers in commits and test names.
Map the profile to your life cycle explicitly, for example which PM tasks happen in iteration planning and which at release, and write that mapping down.
Separate author and checker for key verification tasks wherever the team size allows.
Plan the next step: once Basic is routine, consider Intermediate, the security or testing annexes, or a domain standard your customers require.

Summary and key takeaways

ISO/IEC 29110 is a multi-part series from ISO/IEC JTC 1/SC 7 that gives very small entities (up to 25 people) pre-tailored subsets of the big life cycle standards, called profiles.
Part 4 specifications are normative and are what auditors check; Part 5 guidelines explain, task by task, how to implement each profile.
The generic profile group has four profiles – Entry, Basic, Intermediate and Advanced – forming a roadmap as an entity grows; it is aimed at non-critical work.
The software Basic profile has two processes: Project Management (PM.1–PM.4) and Software Implementation (SI.1–SI.6), linked by the Project Plan, the Software Configuration and change requests.
The series is life cycle neutral, so agile teams can implement it by mapping tasks to their ceremonies and keeping durable records.
Conformity certification under Part 3-2 is a third-party process certification, not a management system or product certificate; self-assessment and process assessment support improvement.
The 2025 International Standard editions of the Entry and Basic guidelines replaced the 2011 Technical Reports and added conditional tasks and annexes for support, testing, accessibility and security.
For safety-critical products, the relevant safety standards still apply; the generic profiles are a foundation, not a substitute.

Reflection questions

Think of a small team you know. Which of the four generic profiles fits it today, and what would have to change for it to move to the next one?
Pick one of your recent projects. Which PM and SI tasks did you actually perform, and which work products existed only in people's heads?
How would you map PM.1, PM.2, PM.3 and the SI activities onto your team's current way of working, whether agile or plan-driven?
A customer offers your company a contract involving safety-related software. How would you explain the difference between your ISO/IEC 29110 practices and what the safety standard requires?
If you had to prepare for a certification audit in six months, which three gaps would you close first, and what evidence would show they are closed?