Establishing and Managing an Audit Program

Lesson 1 covered principles that apply to any single audit. This lesson steps up a level: before a single audit ever happens, someone has to plan, resource, and continuously improve the entire audit program — the coordinated set of audits (one or many, first-, second-, or third-party) an organization or certification body runs over time.

Audit program vs. a single audit

An audit program is not the same thing as one audit event. A single audit has a defined scope, criteria, and duration; an audit program is the ongoing management activity that decides which audits happen, when, by whom, and why — typically spanning a multi-year cycle. Confusing the two is a common early mistake: an organization that treats "we did our internal audit" as a completed, one-off task has not actually established a program, just conducted a single audit.

The audit program manager's responsibilities

Someone — an individual or a small function — must own the program itself, distinct from any single audit's lead auditor. Core responsibilities typically include:

• Establishing program objectives — tied to the organization's own priorities (e.g., verifying readiness ahead of certification, or maintaining certification through required surveillance audits)
• Determining program scope — which sites, functions, and management system areas are covered, and over what time period
• Identifying and evaluating risks — some areas warrant more frequent or deeper audits than others (the risk-based approach principle from Lesson 1, applied at the program level)
• Ensuring auditor competence — assigning auditors (and audit teams) whose competence matches what each specific audit requires, not just whoever is available
• Managing audit program records — schedules, findings history, auditor assignments, program review outcomes

A program manager who is also personally leading every individual audit tends to lose the oversight function entirely — the whole point of separating these roles is that someone maintains a view across the entire program, not just their own most recent audit.

Building a risk-based schedule

Just as Implementer's internal audit lesson covered risk-based scheduling for a single organization's internal audits, a certification body's audit program applies the same logic across its full portfolio of clients and audit types. A few concrete drivers of audit frequency and depth:

• Prior audit history — an area with a history of major nonconformities warrants closer, more frequent attention than one with a clean multi-cycle record
• Significance of change — a client that recently underwent a major system migration or organizational restructuring is a higher priority for near-term audit attention than one that has been stable
• Regulatory or contractual stakes — some scopes (e.g., processing of highly sensitive data) justify deeper sampling and more frequent surveillance regardless of prior history

A schedule built purely on a fixed calendar interval, ignoring all of the above, is a common example of an audit program that technically exists on paper but hasn't actually applied the risk-based approach principle in practice.

Monitoring and improving the program itself

An audit program isn't "done" once it's scheduled — it needs its own feedback loop, echoing Implementer's management review lesson but applied to the audit function specifically. Typical inputs to program-level review include: whether audits were completed on schedule, whether assigned auditors' competence actually matched what each audit needed, patterns across findings that might indicate a systemic issue rather than isolated ones, and feedback from audited parties about the audit process itself (not the findings, but how the audit was conducted). A program that never revisits its own effectiveness — just keeps running the same schedule indefinitely — misses exactly the kind of continual improvement signal the standard expects at every other level of a management system.