Risk-Based Programming

An audit programme allocates a scarce resource. Auditing every process equally each year spends most of it confirming that low-risk processes still work.

What should drive frequency and depth

• Risk — the consequence of failure in that process, for safety, environment, customer or compliance.
• Previous audit results — areas with repeat findings warrant more attention, not the same cycle.
• Change — a new process, new equipment, new supplier, reorganisation or new personnel.
• Performance data — complaints, nonconformities, incidents, rework, delivery failures.
• Regulatory and customer significance.
• Time since last audited, as a floor rather than the primary driver.

Programme design

• Cover the whole system over a defined cycle, but not every part every year at the same depth.
• Audit processes, not clauses. Clause-by-clause audits test the documentation; process audits test the work. Map clauses onto processes for coverage, then audit the process.
• Include interfaces between processes — hand-offs are where systems fail and where departmental audits never look.
• Include shifts other than days, and include contractors and outsourced processes.
• Leave contingency for unplanned audits in response to a problem.