ISO 9001:2015 Internal Audit Findings — The Five Most Common Gaps We See

Clause 6.1 of ISO 9001:2015 — "Actions to address risks and opportunities" — is the single most-flagged gap we see in internal audits of small/mid-cap EMS operations. The standard does not prescribe a methodology, which sounds liberating until you realise it also means an auditor can reject whatever you've put together for being "not systematic." Across the last three years of internal and external audits at our Madurai facility, this clause has produced more minor non-conformities than any other.

The pattern is consistent. Teams produce a risk register at certification, list 20–30 risks (supplier delay, machine breakdown, operator error, customer churn), assign owners, and then never touch it again. At the next surveillance audit the dates on the document are 18 months old, half the listed risks have actually materialised without anyone updating the register, and the "actions" column is empty for the ones that haven't.

What auditors expect to see

• Review cadence in writing — quarterly review meeting minutes, attendance, and the deltas from the previous register.
• Linkage to PDCA — when a risk materialises, evidence that the corrective-action loop fed back into the register (and that similar risks were reassessed).
• Quantification — even a simple severity-likelihood matrix (1–5 each, multiplied) beats narrative descriptions. Auditors will accept a crude number; they will not accept "high/medium/low" without a definition of each.
• Opportunities tracked too — not just risks. Most teams forget this and lose half a clause's worth of marks.

"Eighty percent of our 6.1 findings disappeared the year we moved the risk register from a Word document to a shared sheet with automatic monthly reminders. The methodology did not change. The cadence did." — Pioneer Horizon quality lead

The fix is a recurring calendar invite, not a new framework. Pick one owner per risk, force a 30-minute quarterly review, and capture the deltas in the document itself.

Clause 7.1.5 covers monitoring and measuring resources. In an EMS context this means every device that takes a measurement used to accept or reject product — solder-paste height gauges, AOI cameras, ICT fixtures, temperature profilers, torque drivers, thermocouples, micrometers. The auditor's question is always the same: show me that the device that measured this lot was in calibration at the time the measurement was taken.

The gap we see most often is a calibration sticker on every instrument but no traceable record back to the lot. The sticker says "calibrated 12-Mar-2025, due 12-Mar-2026," but there is no log entry saying "lot PH-2025-08-2241 was measured at 09:15 on 18-Jul-2025 using thermocouple TC-014 (cal cert 4421)." The certification is there; the traceability is not.

What we record at every measurement event

1. Instrument ID and serial.
2. Current calibration certificate number and expiry date.
3. Operator ID.
4. Timestamp.
5. Measured value(s) and pass/fail outcome against the recorded spec.

This is five fields in our MES per measurement. It costs the operator no time because the MES pulls instrument and cert data from a tag scan. The audit value is enormous — when an auditor asks "what was the reflow profile peak for lot X?", we answer in 90 seconds with timestamped data and the cert that was valid for the thermocouple at that moment.

Out-of-calibration impact analysis

The other half of 7.1.5 is what you do when an instrument is found out of calibration retroactively. The standard requires a documented impact assessment — every lot measured since the last known-good calibration has to be reviewed. We have a standing query that returns this list in under a minute, which is what saved us during one external audit when a temperature profiler drifted between scheduled cals. The query identified 47 affected lots; 44 had been measured well inside the pass band; 3 were re-measured against the customer spec. No recall, no NCR.

For the underlying traceability schema we use, see per-board traceability.

Clause 8.5.3 — "Property belonging to customers or external providers" — catches teams off-guard because EMS engineers rarely think of customer-supplied IP, drawings, or tooling as "property." Auditors do. In one surveillance audit we lost a minor for not having a documented control list of customer-furnished CAD files, Gerbers, and BOM revisions, even though every file was sitting in version control with full history.

The standard wants three things, in writing:

• Identification — what customer property do you hold, where is it, what version is it.
• Verification — when it arrives, evidence that you checked it for completeness, damage, or revision mismatch.
• Protection — physical/logical security controls and what happens if it's lost or damaged (including the customer-notification step).

Common types of customer property we explicitly track

• Gerbers, ODB++, and CAD source files.
• BOM spreadsheets and engineering-change notices.
• Consigned components (especially for high-allocation parts the customer supplies).
• Test fixtures and golden-sample boards provided for ICT or functional test.
• Branding artwork (silk-screen logos, label artwork) where the logo is a registered mark.
• Firmware binaries and signing keys (a separate clause 8.5.3 and 7.5.3 issue).

For each, the audit record shows arrival date, version, hash (for digital files), storage location, access list, and disposal date if the programme ends. We treat firmware signing keys as the highest-tier customer property — they live in an HSM with a dual-control access log, and the audit trail for any signing operation is retained for the contractual life of the product plus seven years.

The "we lost something" procedure

The clause also requires a documented procedure for loss or damage. Ours is one page: who notifies the customer, in what timeframe, with what level of root-cause detail, and the path back to clause 10.2 (nonconformity and corrective action). The procedure has been used three times in five years. Each invocation produced a clean audit trail — which is the entire point.

Clause 9.2 mandates internal audits at "planned intervals." The phrase is deliberately vague — annual minimum is the unwritten norm, but auditors will check whether the cadence matches the risk profile of the process. The most common failure is not the cadence but the scope: teams audit the same five processes (incoming inspection, SMT, hand-soldering, ICT, dispatch) every year and never touch HR, training records, or supplier evaluation. Those are also part of the QMS.

The audit programme we run

Every QMS clause is on a rolling 18-month audit cycle. High-risk processes (production, calibration, traceability) get audited twice a year. Lower-risk processes (document control, management review) once per cycle. The audit calendar is published a year in advance with auditor assignments. Auditors do not audit their own department — this seems obvious but is a recurring finding.

Audit findings that fix the system

The point of internal audit is not to score the team; it's to find issues before the external auditor does. We measure two metrics on the internal audit programme:

1. Finding rate — internal findings per audit-day. Below ~0.5 means the auditors are rubber-stamping; above ~2 means scope or training is wrong.
2. Internal-to-external ratio — internal findings divided by external findings. We aim for >5:1. If the external auditor finds things we missed, our internal programme is not earning its keep.

The most-missed sub-clause in our experience: 9.2.2(e) — "ensure that the results of the audits are reported to relevant management." Findings that sit in a folder do not satisfy this. Findings that show up on a management-review agenda with status (open/closed) and root cause do.

Auditor competence (clause 7.2)

Internal auditors need documented training and demonstrated competence. We require: ISO 9001 lead-auditor course (32-hour), shadowing two audits before leading one, and an annual refresher. Auditor competence records are part of the audit programme evidence — auditors who haven't refreshed are not assigned. This is a quiet 9.2 gap that surfaces when external auditors check 7.2 evidence for the named internal auditors.

Clause 10.2 covers nonconformity and corrective action. Every QMS has a CAPA system; few have one that actually reaches root cause. The most common failure mode: a nonconformity gets logged, a correction (rework, scrap, replace) is recorded, and the corrective-action field reads "operator counselled" or "re-trained." That's not root cause; that's a polite way of saying "we don't know why."

The five-whys discipline

Our CAPA template requires five whys per nonconformity, even when the answer feels obvious by the third. The discipline is in writing them down — when an auditor reads "operator placed wrong component" and the next why is "no poka-yoke on similar packages," they see a system gap, not a human-error excuse.

A worked example from our floor last quarter: a 0805 capacitor was placed at the position intended for a 0603. Five whys:

1. Why? Operator picked from the wrong feeder.
2. Why? Feeder layout for that programme had two visually similar parts in adjacent positions.
3. Why? Feeder-assignment algorithm minimises operator walking distance; it does not consider visual confusability.
4. Why? Visual confusability is not a parameter in the MES.
5. Why? We never asked for it — it is not in our DfMA review checklist.

The corrective action wasn't "re-train the operator." It was a software change to the feeder-assignment algorithm and a new line on the DfMA checklist. That action prevents the failure mode across all future programmes.

Effectiveness verification

Clause 10.2.1(e) requires reviewing the effectiveness of corrective action. Most teams close the CAPA when the action is implemented. We close it when the recurrence-rate metric for the failure mode has been measured for at least 90 days post-implementation and is at or below target. The CAPA stays "in verification" until then. About 15% of CAPAs reopen at verification — those are the ones that taught us the most.

For a starting point on building these workflows, browse our broader traceability article, or talk to our compliance team about how we wire CAPA into the MES.