ISO 29110 EP3: How to Prepare for the Certification Audit

EP3 is a preparation playbook from the day you decide to get certified to the day of your Stage 2 audit — written from the experience of the Grand Linux Solution team, which has passed ISO 29110 audits continuously for 10 years since 2015 (4 certificates) and passed every surveillance audit.

This article is for:

• Small-to-medium software teams (VSE) pursuing ISO 29110 for the first time
• Team leads / PMs who must build a preparation roadmap
• Developers assigned as document or process owners
• Executives approving budget and resources for certification

Who Has to Be Audited

ISO/IEC 29110 was designed for VSEs (Very Small Entities) — organizations, projects, or teams with up to 25 people working on software development (per ISO/IEC TR 29110-1). In practice, many larger companies apply it to sub-teams or business units that fit the VSE definition.

Who should pursue certification

Group	Why they pursue it
Software vendors serving government	Many public-sector TORs require ISO 29110 as a baseline qualification
System integrators on enterprise projects	Large customers use it as a vendor-screening filter
In-house dev teams at large companies	Demonstrates internal team meets the same standard as external vendors
Software startups / SMEs entering enterprise market	Lowers the barrier to engaging enterprise customers
Government units developing software in-house	Aligns with digital-government policy and raises the quality bar of public-sector systems

"Who gets audited" isn't one person — it's the whole team. Auditors interview people in their actual roles, not just executives. See the role matrix below for details.

4 Things to Know Before You Start

1. There are 4 profiles — pick the one that fits

Profile	Best for	Notes
Entry	Brand-new tiny teams, single project	A stepping stone before Basic
Basic	Teams ≤25, multiple projects — most common	Based on ISO/IEC 29110-4-1 — the de facto standard in the Thai market
Intermediate	Multi-project teams needing portfolio management	Still maturing / less common
Advanced	Mature teams aiming for ISO/IEC 12207 or CMMI	Still maturing / less common

The profile that Thai companies and government bodies recognize most is Basic. The certificate Grand Linux Solution holds is Basic Profile under ISO/IEC 29110-4-1:2018.

2. Two process groups must be implemented

Process	Focus	Owner
Project Management (PM)	Plan, track, close out a project, manage risk and change	Project Manager
Software Implementation (SI)	Analyze requirements, design, code, test, deliver, maintain	Tech Lead / Software Engineer

3. Standards you must read (at least 3)

• ISO/IEC 29110-4-1:2018 — Profile specifications (what you're audited against)
• ISO/IEC TR 29110-5-1-2 — Management and engineering guide (the main working reference for the team)
• ISO/IEC TR 29110-3-1 — Assessment guide (what auditors use)

Main standards are sold via the ISO Store. Technical Report 5-1-2 can be read for free on the ISO Online Browsing Platform.

4. Vocabulary your team must speak

Term	Meaning
VSE	Very Small Entity — a software team ≤25 people
Work Product	Document or output the process produces (Project Plan, Test Report, etc.)
CB	Certification Body — issues the certificate (e.g., TÜV NORD, SGS, BV)
NC	Non-Conformity — something that doesn't meet the standard (Major / Minor)
OFI	Opportunity For Improvement — a suggestion, not an NC
Surveillance	Annual mini-audit during the 3-year certificate validity
Traceability	Linkage between Requirement → Design → Code → Test

6-Month Preparation Timeline (Real Example)

Month	Main work	Expected outcome
Month 1	Kickoff, form preparation team, gap analysis	Gap report + action plan
Month 2	Draft process manual, select CB, request quotes	Process Manual v1 + CB chosen
Month 3	Pilot the process on one project, start producing real work products	Pilot project running on the process
Month 4	Roll out to all active projects + team training	Every active project has complete work products
Month 5	First internal audit + close NCs + management review	Internal audit report + corrective actions
Month 6	Stage 1 audit (document review) → Stage 2 audit (on-site)	Certificate

Role Matrix — Who on the Team Participates

Role	Main responsibility	Likely audit-day question
Executive Sponsor (MD / leadership)	Approve resources + budget, chair management reviews	"How do you use management-review outcomes to make decisions?"
Quality Manager / Process Owner	Own the QMS, schedule internal audits, track NCs	"Show the process document and its revision history"
Project Manager	Own Project Plan, Status Report, Risk Register	"Show the project plan of an active project + change-request log"
Tech Lead / Software Architect	Own Software Design and architecture decisions	"Show the design document and trace back to requirements"
Developer	Write code following process, commit per convention, review	"Explain your code-review process and show a pull request"
QA / Tester	Own Test Cases, Test Report, defect log	"Show a test report + a defect traced back to a requirement"
Internal Auditor	Audit processes internally before the external audit	"Show the internal audit report and closed NCs"
Document / Configuration Owner	Maintain document repository and version control	"Show document versioning and backup policy"

One person can wear multiple hats if the team is small — but the Internal Auditor cannot audit a process they own (conflict of interest).

Work Products You Must Prepare

The Basic Profile defines minimum work products across the two processes — this is the list auditors actually ask for:

Process	Key work products	Owner
Project Management (PM)	Statement of Work	PM + Customer
	Project Plan (timeline, resources, milestones)	PM
	Risk Register + Mitigation Plan	PM
	Change Request Log + Approval Trail	PM + Customer
	Progress / Status Report	PM
	Acceptance Record (UAT Sign-off)	PM + Customer
Software Implementation (SI)	Requirements Specification	BA / Tech Lead
	Software Design (architecture + components)	Tech Lead
	Source Code (controlled in VCS)	Developer
	Traceability Matrix (Req ↔ Design ↔ Code ↔ Test)	BA + QA
	Test Cases + Test Report	QA
	Defect Log + Resolution	QA + Developer
	User Manual + Installation Guide	Tech Writer / Dev
	Maintenance Plan	PM + Tech Lead

The 3 golden rules of work products

1. "Show me the evidence" — Real artifacts from real projects, not empty templates
2. Reviewed + Approved — Key documents must have a review/approval trail (signatures, comments, pull-request reviews)
3. Versioned — Every document has version history or revision dates

Systems and Tools You Need

• Version Control System — Git (GitHub, GitLab, Gitea, Bitbucket) for source code and text-based documents
• Issue Tracker — Jira, Redmine, GitHub Issues, Azure DevOps — for requirements, defects, change requests
• Document Repository — SharePoint, Confluence, Google Drive — with access control and version history
• CI/CD Pipeline — Jenkins, GitLab CI, GitHub Actions — evidence that builds and tests are automated and repeatable
• Communication Log — Archived Slack/Teams + email — used as evidence for change requests and approvals
• Backup + DR plan — These systems must be recoverable. See Disaster Recovery for guidance

You don't need expensive tooling — open-source and free tiers are fine — but they must be used consistently and for real work.

Pre-Audit Checklist (4 Weeks Before)

One month before the Stage 2 audit, your team should pass this checklist:

Item	Acceptance criteria
Process Manual	Published + signed off + the team knows where it lives
Sample project work products	All required types present in at least one active project
Traceability matrix	Req → Design → Code → Test complete, no orphans
Internal audit report	Done at least once — all NCs closed
Management review minutes	At least one review with a decision log
Training record	Everyone on the team has been onboarded to the process
Sample project change requests	Approval trail complete
Test report for latest release	Traceable back to requirements
Document version control	Revision history can be displayed instantly
Mock audit (dry run)	One rehearsal — verify the team gives consistent answers

Audit Day — Mindset and How to Answer

3 mindset shifts

1. The auditor is here to help, not to trap you — Their job is to verify the standard is genuinely implemented
2. "I don't know, let me check" beats guessing — Wrong guesses trigger follow-up questions you don't want
3. Show the system you actually use, not documents made for the audit — Experienced auditors recognize the pattern

Preparing for the day

• Prepare 1-2 active projects with complete, fresh work products
• Make sure everyone knows the audit scope and their own role
• Open real screens / live systems during interviews — live demos beat PDFs
• Have a backup machine + backup internet — losing connectivity mid-audit is a red flag
• Assign a note-taker to capture findings in real time

Example questions and good answers

Auditor's question	Good answer
"Show the requirements for project X"	Open the actual issue tracker / SharePoint folder and show revision history
"Trace this defect back to a requirement"	Open the traceability matrix and follow real links
"Who approved this change request?"	Open the CR log and show the approval (email, ticket comment, PR review)
"What did the latest internal audit find?"	Open the internal-audit report, the corrective-action plan, and the evidence that NCs are closed
"How does the team know this process?"	Show training records and the actual links the team uses to read the process

7 Common Preparation Mistakes

1. Starting preparation 1 month before the audit — Not enough. Plan for at least 4 months if you're starting from scratch
2. One person writes all the documents — Auditors interview multiple people; a document whose "owner doesn't use it" gets caught in interviews
3. Copy-pasting empty templates — A Process Manual you can Google doesn't reflect real work. Write your own
4. Skipping the internal audit — It's a mandatory requirement and reduces surprises at Stage 2
5. Documents created just for the audit — Auditors detect this from clustered revision dates or batch-like filename patterns — see EP2: 5 most common reasons teams fail
6. Letting a consultant do everything — Consultants help, but the process must belong to the team or interview answers won't line up
7. Executives skipping management reviews — Management review is mandatory, and there must be evidence that leadership uses its outputs to decide

About Saeree ERP — 10 Years of ISO 29110

Grand Linux Solution Co., Ltd. has held ISO/IEC 29110 Basic Profile since 2015 and renewed continuously for 10 consecutive years across 4 certificates (2015-2018, 2018-2021, 2021-2024, 2024-2027). The current certificate is issued by TÜV NORD under ISO/IEC 29110-4-1:2018, valid 13 Nov 2024 - 12 Nov 2027, with surveillance audits passed every single year.

Every Saeree ERP project delivered to a customer follows the same process — not just on audit day. Project Management Plan, Requirements Specification, Test Report, User Manual, and Maintenance Plan for every deployment are fully traceable and available for customer audit at any time.

See also: Receiving the ISO 29110 certificate and Why Saeree ERP.

Summary — 3 Sentences to Remember

1. Preparing for ISO 29110 means changing how you actually work — not writing new documents
2. The auditee is the whole team, not the executive alone — auditors interview real roles
3. A certificate lasts 3 years with annual surveillance — teams that "prepare for the audit only" fail at the first surveillance

Preparing for ISO 29110 isn't hard because the standard is hard — it's hard because you have to change how the team works every day. Once you can, the certificate becomes a side effect; the real outcome is a team that delivers the same quality every time, for 10 consecutive years.

— Grand Linux Solution

Related articles:

• What is ISO/IEC 29110? Why software companies should pursue it
• ISO 29110 EP2: Certification & Audit Process
• What is ISO 27001? Information-security standard every organization should know

References

• ISO/IEC 29110-4-1:2018 — Profile specifications: Generic profile group
• ISO Online Browsing Platform (free read for TR 29110-5-1-2)
• International Accreditation Forum (IAF) — verify CB accreditation
• TÜV NORD — issuer of Grand Linux's current certificate

This article is written from the real-world experience of the Grand Linux Solution team, which has passed ISO 29110 audits continuously for 10 years since 2015 — contact sale@grandlinux.com or call +66 2-347-7730.