Transition to Process Auditing

Auditing with the Process Approach

ISO 9001:2000 promotes the process approach by its structure and requirements. Yet, many internal audit programs still conduct audits by clause instead of by process. A “process” is an activity that uses resources to transform inputs into outputs. The output of one process is often the input to another process. The “process approach” identifies the system of related processes, along with their interaction and management.

Organizations must identify and manage numerous linked activities to function effectively. As a result, internal audits should examine these activities from a process perspective. An audit based on the process approach looks at more than just the tasks for a selected activity. It examines process inputs, resources, and outputs.

Audits are often scheduled and conducted on a specific clause of the standard. This isolated focus on judging conformity to a single set of requirements may result in the broader business process being inadequately assessed.

If an audit schedule is set up by clause, the schedule is dictating a limited audit scope. Even processes related to a unique clause usually involve multiple departments and should be followed into those other areas for complete coverage.

When audits are scheduled by department, they usually stop at the department boundaries and don’t go into other areas to examine the inputs and outputs. In addition, these departmental audits may only review documentation to judge conformity and not focus on interviews and observations for a more balanced view.

ISO 9001:2000 promotes the adoption of the process approach by the very nature of its structure and requirements. In fact, the quality manual must describe the interaction between the processes of the quality management system. Therefore, internal audits need to keep pace and make the transition to “process auditing” to avoid the limitations of clause and departmental auditing.

How do you schedule process audits?

Internal audits should be scheduled by key processes. Even if you stick to a department-based schedule, extending it to consider supplier and customer departments would be an improvement.

Audits are to be planned based on the status and importance of the area to be audited, as well as, the results of previous audits. If an area has experienced many quality problems, then it deserves more audit scrutiny. Similarly, if an area is critical to product conformity, it should be audited more often. And, areas receiving most of the audit nonconformities should be scheduled to receive more frequent audits.

Many organizations have described the interaction of their processes by including a process map in the quality manual. This flowchart can be used to arrange process audits. The process interface information can be placed in a supplier-customer relationship table for easier identification of the linkages.

Supplier-Customer Table

A supplier-customer table can be used to clearly identify the internal “supplier” processes and “customer” processes for a process. If Process 2 in the partial table below is to be audited, reading across the row shows that Process 1 is a supplier and Processes 3 and 4 are customers.

Process 1 Process 2 Process 3 Process 4
Process 1
“Process 2”
Process 3
Process 4

When planning an audit, identify the audit criteria. The requirements include those from ISO 9001:2000, the organization, and its customers. Also, identify any applicable legal requirements. For ISO 9001:2000 requirements, keep in mind its “plan, do, check, act” structure. Therefore, one logical requirement may be addressed at several places in the standard.

Responsibility Table

A Responsibility Table can be used to identify process owners and users. It also identifies the applicable clauses to address when auditing a process or department. In the table below, Quality has Primary responsibility for document control (4.2.3). The other departments have a secondary role since they use the process.

Two versions of the table may be appropriate. One, as shown below, displays the relationship between departments and ISO 9001:2000 clauses. A second table could show the relationship between departments and processes.

. . .
. . .
. . .

After the table is completed, all the process owners (those responsible for the applicable clauses) will be identified. These process owners will approve their related documents and involve the Secondary areas in the reviews. In some cases, the area may not have any direct involvement in the process and will be shown with a hyphen. Of course, the sample table above may not reflect the responsibilities at your organization.

When auditing an area, the auditor can look down a column to see the clauses of primary and secondary importance. The table cells with a hyphen can be skipped since they aren’t applicable for that area.

Requirements Table

Another useful planning tool is the Requirements Table. After identifying the applicable requirements (standard, customer, company, and legal), place them in the first column of a table. Identify the processes that address these requirements in the other columns. Then show the process flow for each requirement as the rows of the table. This table will ensure the process audit is customer focused and deals with the full range of requirements. It can be used to create the process checklist.

Are checklists used any differently?

Yes. A checklist is usually prepared to verify a documented process is in place and being followed. Unfortunately, checklists are limited by the content of the process documents and may not adequately address the process inputs, outputs, controls, and results (effectiveness). And, with defined, undocumented processes, checklists may not have been created due to the lack of source documents.

Checklists should move from specific questions to an outline format to encourage more thinking by the auditors, as well as, help them spot audit trails and evaluate effectiveness. Detailed questions in a checklist often result in auditors strictly adhering to those questions and not being flexible enough to follow audit trails.

The notes on the checklist should identify not only evidence of any nonconformities, but also process strengths (for compliments) and weaknesses (for improvements).

Process Checklist Example

Audits must consider four types of requirements: standard, customer, company, and legal. Many of these requirements are documented and the reference number can be listed in the first column of the checklist. If a requirement is defined, but not documented, the source should still be identified.

The second column lists the requirements to be “looked at” and the third column lists the evidence to “look for” to judge conformity. Also, identify the objectives for the process in the requirements column. You can only determine the process effectiveness by looking at the quality objectives and the process results.  

Reference (Document) (Look at) Requirement (Look for) Evidence of Conformity
Selected Process
(clause n.n.n)
Specific requirement
(including objectives)
Review documents
– Understand “documented” process
– Check document availability
– Verify document controls
Interview personnel
– Talk to the process owner
– Identify process linkages
– Determine responsibilities
– Review their competencies
– Check their understanding
– Understand “defined” process
Observe operations
– Verify adequate resources
– Assess current practices
– Review process monitoring
– Evaluate process controls
Examine records
– Check record management
– Confirm the practices
– Review process performance
Evaluate process
– Determine conformity
– Assess effectiveness
– Identify improvements
“supplier” process < (upstream audit trail) Review output of supplier process as
acceptable input to audited process.
(downstream audit trail)  > “customer” process Review output of audited process as
acceptable input to customer process.

Some auditors enjoy talking to people and observing the work, but may shy away from closely examining documents and records. Other auditors may be less outgoing and prefer to focus on auditing the “books”. For a balanced audit, you must collect objective evidence from all four sources: documents, interviews, observations, and records.

Documents must be reviewed to prepare for the audit. People must be interviewed to learn about the process and evaluate their understanding. If possible, the activities are observed to compare practices to the defined process. Documents in use are evaluated for proper document control. Records must be examined to assess past practices. Only through sampling all four sources can you confidently determine conformity and judge effectiveness.

How is auditing by process any different than auditing by department?

Department audits may assess portions of multiple processes, but not fully cover a single process. A process audit may span multiple departments to examine the full process, including the sources of its inputs and the recipients of its outputs. So, a process audit is really quite different than a department audit. Process audits look at the sequence and interaction of the processes and aren’t limited by the artificial boundaries of an organizational structure.

Auditors must be trained to look for more than just conformity. Auditors should have a business perspective. They need knowledge of the process and its measurable objectives, so they can identify and follow audit trails. The auditors must also examine process effectiveness and identify any opportunities for improvement.

The key processes and linkages of the system will have been identified (since required by ISO 9001:2000). Using this process description, auditors can follow the flow from orders to shipping. Of course, the processes for the infrastructure won’t be in the direct process flow for the product, but even those processes have inputs, outputs, and controls.

Process auditing is really auditing of a process-based system. It goes beyond limited auditing (by clause or department) to look at process interactions. Process auditing involves making value-added judgments about the process and its effectiveness. When auditors go upstream (to look at inputs) and downstream (to follow outputs), they are performing process audits that allow them to examine the process interactions.

I have found that the more significant problems exist at the interfaces between processes, not within a process. The handoffs between processes are typically ignored in audits conducted by clause or even department. You need to look at the inputs to the process and the outputs from the process.

To judge effectiveness, auditors can evaluate how well the process is being performed by looking at its quality objectives and measurements. In some cases, the auditor may have to go downstream to see how well the process output is meeting the needs of the next process. Look beyond the requirements, determine what process outcomes are expected by management.

How do you audit the department interfaces without jumping all over the place?

When auditors follow an audit trail upstream and downstream, they may be undecided about how far to continue on that path. Carried to its extreme, one process audit could end up looking at every process in the system. Well, that is what should happen over time, just not all at once.

Start with the inputs from the “supplier” processes and follow them into the activities of the selected process. Then follow the outputs to the “customer” processes to ensure they have been transferred or communicated as required.

Don’t start and end the audit at the boundaries of the process. You need to begin with the outputs of the preceding processes (inputs to the selected process) and continue auditing through the delivery of the outputs to the succeeding processes (which are their inputs).

You need to see if there are any gaps or overlaps between the selected process and the “supplier” and “customer” processes. This assessment will allow you to make judgments on the conformity and effectiveness of the selected process.

Depending on the audit scope, team size, and allocated time, you could audit a collection of processes that make up a sub-system.

What is the difference between “system” audits, “process” audits, and “product” audits? 

A “system” audit is an assessment of the overall quality management system. When the system is further divided into unique processes, the system audit has become, in effect, multiple “process” audits.

A “process” audit is an assessment of a single process or group of linked processes. It should address the process inputs, resources, activities, outputs, controls, and measurements.

In some circles, a “product” audit is an assessment of products that have passed final inspection. For example, a dock audit typically checks for correct packaging, labeling, and paperwork, and may even test the product again before shipment.

In my opinion, an “audit” that involves product inspections or tests isn’t really an audit. It is an inspection or test. Audits examine processes, including those that inspect or test the product, but do not verify the products directly.

Therefore, I define a “product” audit as just a process audit with a scope limited to a specific product (the subset of processes relating to that product). In a similar fashion, a process audit can be focused on a specific contract or project, giving rise to a “contract” audit or “project” audit.


ISO 9001:2000 is causing organizations to view their quality management system as an integrated set of processes. Internal audits should adopt this same process approach. Audits should not be limited by artificial scopes and assess only standalone departments or clauses.

Process auditing goes beyond just looking at documents to evaluate conformity. They are more interview-based and extend into the linked processes to examine input sources and output destinations. They should give management a clear picture of the system conformity and its effectiveness in meeting planned results.