Process-based auditing examines how activities combine to produce intended results. Rather than treating the quality management system as a collection of separate clause files, the auditor follows actual work through its inputs, decisions, controls, outputs and interactions with other processes.
The method supports the wider internal audit programme. It does not remove the need to evaluate applicable requirements. It changes how evidence is organised so that the auditor can see whether the organisation’s arrangements work together.
Define the process result and boundaries
Start with what the process is intended to deliver and to whom. An order-review process might provide an agreed specification that operations can fulfil. A purchasing process might provide suitable externally supplied products or services when needed.
Identify where the process begins, where it ends and which handovers affect its result. Organisational charts can help locate responsibility, but a department boundary may not be a meaningful process boundary. An order change can cross sales, engineering, planning and production before reaching release.
The auditor needs enough context to understand relevant criteria. This can include customer requirements, adopted procedures and applicable QMS obligations. A process map is a useful explanation, not proof that the depicted sequence is implemented.
Follow one trail before generalising
Select a case relevant to the audit objective. Trace the input, decisions, resources, records and output. Ask how exceptions were handled and how the result was accepted. This provides a concrete basis for understanding the claimed arrangements.
For a fictional installation service, the trail could begin with a customer site requirement. The auditor follows its review, assignment of competent personnel, preparation of equipment, installation checks and handover. If an external contractor performs a step, examine the relevant control and interface rather than treating outsourcing as the end of the audit.
One case can reveal an important weakness, but broader conclusions require proportionate additional evidence. Consider variation across service types, locations or unusual conditions when deciding what else to examine.
Evaluate controls at the handovers
Interfaces are often where requirements lose context. A specification may be correct in the sales system but incomplete on the production instruction. A supplier deviation may be accepted locally without reaching the person responsible for customer approval.
Ask who transfers information, who receives it and how acceptance is confirmed. Examine what happens when information changes or is incomplete. The existence of two well-written departmental procedures does not show that their interface works.
| Handover | Potential audit question |
|---|---|
| Sales to operations | How are customer changes reflected in the current work instruction? |
| Purchasing to receiving | Which acceptance conditions accompany the delivery? |
| Inspection to release | How does the releaser know unresolved results remain? |
| Complaints to improvement | Who evaluates whether similar cases are affected? |
These prompts need adaptation to the organisation. They are not a universal list of required forms or approvals.
Connect results to the planned method
A process can appear well documented yet fail to deliver consistently. Review performance information, customer feedback and relevant problems alongside records of implementation. Understand how the organisation defines the measures before treating favourable results as assurance.
Conversely, a favourable outcome in one case does not excuse an unmet requirement. A product may pass a final test even though a required release control was bypassed. Evaluate both the applicable arrangements and the evidence of results.
Where performance deteriorates, ask how the process owner investigates and responds. A chart that nobody reviews may provide data without effective management. The audit should examine whether information reaches people who can act.
Retain coverage of applicable requirements
Process-based auditing is not an excuse to omit requirements that are less visible in a transaction trail. Programme planning and coverage reviews can help connect requirements to the processes where they apply.
An auditor might examine competence through an operational trail, document controls through the instructions used and corrective action through a recent problem. Some subjects may also need dedicated enquiry. The point is to evaluate their practical application rather than collect disconnected documents for each clause.
A coverage matrix can be useful, but it should not dictate the finding in advance. It records what needs attention and what was examined; it does not replace evidence-based conclusions.
Report the system relationship clearly
Describe how the evidence affects the process result or interface. A finding that an updated specification did not reach production is more informative when it identifies the failed handover and relevant requirement, rather than merely naming a department.
The audit evidence examples explain how to preserve the links between records, observations and conclusions. Keep sample limitations visible so management understands what the trail supports.
A process-based audit is successful when it helps the organisation understand how its system behaves in practice. Its output should make effective controls, weak interfaces and justified actions clearer, with enough evidence that responsible managers can investigate and respond.
Following an unsuccessful case can be particularly informative. It shows how the process identifies unsuitable results, contains consequences and learns from them, rather than merely demonstrating the route taken by straightforward successful work.