Guide · ~12 min read

ISO 9001 clause 7.5, in plain English.

Clause 7.5, "Documented information". Is the single most-flagged finding in SMB ISO 9001 audits. Not because the requirement is unreasonable, but because it's usually translated by consultants into a binder system that starts drifting from reality the day it's installed. This guide explains what 7.5 actually asks for in normal English, the three findings every SMB manufacturer eventually gets, and what a digital-first answer looks like , without selling you a $250,000 MES.

What clause 7.5 actually says

Three sub-clauses, one core idea

Clause 7.5 breaks into three sub-clauses. 7.5.1 is a scope statement, you need documented information. 7.5.2 covers creating and updating (it has to be identifiable, in an appropriate format, and reviewed for suitability). 7.5.3 is the big one and breaks into two further parts: 7.5.3.1 says documented information has to be controlled, available where needed, and protected from loss / unauthorised change. 7.5.3.2 spells out the controls: distribution, access, retrieval, storage, preservation, change control, retention, and disposition. The core idea: you have to KNOW what version is authoritative, the people who need it have to be able to FIND it, and you have to be able to PROVE nothing was changed without a record.

  • 7.5.1. Scope: you need documented information at all
  • 7.5.2. Creating & updating: identified, formatted, reviewed
  • 7.5.3.1. Controlled: available, protected from loss / change
  • 7.5.3.2. Controls: distribution, access, retrieval, storage, change
  • Core idea: authoritative version + findable + provable
The three findings every SMB eventually gets

Where binder systems fail

Finding 1: obsolete revision in use. Engineering moves the master to rev F, the floor copy stays at rev D, the auditor walks the line and flips to the station copy. Five-minute finding. Finding 2: distribution gap. The official copy lives in the engineering server, the floor has a printed copy in a binder, and nobody can show how a change in the server makes it to the binder in less than a week. Finding 3: change history gaps. The master binder shows revs A through F, but the auditor asks "who approved rev D?" and the trail goes cold. All three are 7.5.3 findings, all three are caused by paper systems, and all three close on the same day you replace the binder with a database row.

  • Obsolete revision in use (7.5.3.2 b). Most common SMB audit finding
  • Distribution gap (7.5.3.2 a). Server master vs. floor copy drift
  • Change history gaps (7.5.3.2 d). Who approved each revision, when
  • All three caused by paper systems
  • All three structurally impossible with a single-source-of-truth database
The "current revision in use" trap

Why this finding never stops

Binder systems can theoretically pass 7.5.3. You just need a distribution log, a revision control sheet, and someone whose job is literally to walk every station after every revision and swap the binder. In a 50-person shop that person works full time on document control, which most SMBs cannot afford. So they skip it, and the gap opens. Tablet-based work instructions close the gap at the architecture level: there is no floor copy to drift because the floor reads the database row in real time. When engineering bumps to rev F, the next badge-in at the station renders rev F. Nobody walks the line, nobody swaps a binder, nobody has to.

  • Binder distribution requires a full-time document controller in big shops
  • Most SMBs skip it, get cited, promise to do better, get cited again
  • Tablet kiosk reads the database row at render time. No floor copy
  • Engineering edits → next operator badge-in renders the new version
  • The finding becomes structurally impossible, not just policy-prohibited
What a digital-first answer looks like

Three properties your system needs

A digital work-instruction system that passes 7.5 needs three properties. One: single source of truth. The authoritative version lives in one database row, and the floor reads that row, period. Two: version history. Every save bumps the version, stamps the editor, and stores a snapshot. So 7.5.2 (identification of changes) and 7.5.3.2 d) (change control) are both answered automatically. Three: append-only history. The version log cannot be edited after the fact, including by the admin. So 7.5.3.1 (protection from unauthorised change) is enforced at the database level, not in app code. Ignite Lean is one system that has all three; there are others. The point is the three properties, not the vendor.

  • Single source of truth. One row, kiosk reads it directly
  • Version history with editor + timestamp on every save
  • Append-only. Old versions cannot be edited, only viewed
  • Per-version snapshot (editable + rendered) so the auditor sees the exact pixels
  • Latest revision rendered automatically on the floor on next badge-in
  • Role-based access enforced at the database (not the app)
Version history current v4
  • v4
    Eric Flint current
    May 17, 2026 · 2:22 PM · changed torque to 12 ft-lb
  • v3
    Maya Rodriguez
    May 14, 2026 · 9:48 AM · updated bolt callouts
  • v2
    Jorge Lee
    May 09, 2026 · 11:04 AM · added rotor close-up photo
  • v1
    Eric Flint
    May 05, 2026 · 4:15 PM · initial publish
A 90-day audit-prep timeline that actually works

What to do, week by week

Most SMBs hit the audit window in panic mode at week 12. Here's the inverse: weeks 1–2, inventory your current work instructions and pick the top 20 by usage. Weeks 3–6, convert them to the digital system, one a day. Weeks 7–8, pilot at two stations and capture the operator feedback. Weeks 9–10, roll out plant-wide and retire the binders. Weeks 11–12, dry-run the audit with the QMS manager: pick five units from build history, ask the same questions the auditor will ask, time the answer. If every answer comes in under two minutes, you're ready. If anything takes longer, that's the gap to close.

  • Weeks 1–2: inventory + prioritise top 20 WIs by usage
  • Weeks 3–6: convert one WI per day; engineering owns the pipeline
  • Weeks 7–8: pilot at two stations; capture operator + supervisor feedback
  • Weeks 9–10: plant-wide rollout; retire paper binders for converted WIs
  • Weeks 11–12: dry-run audit; if every answer takes <2 min, you're ready
  • After the audit: monthly review of WI version-history activity as KPI
Beyond clause 7.5

The other clauses tablet-based MES quietly covers

Clause 7.5 is the headline, but the same architecture that solves it also covers 8.5.1 (control of production. Build records), 8.7 (nonconforming output. Defect flag + supervisor disposition), 9.1 (monitoring & measurement. Cycle time, defect pareto), 9.2 (internal audit. Searchable build history), and 10.2 (corrective action, attributed approvals with reason text). Most SMBs implement 7.5 as a one-off project; they end up de-risking five other clauses as a side-effect. That's the ROI conversation worth having with your QMS manager before you scope the budget.

  • Clause 7.5. Controlled, current, available documented information
  • Clause 8.5.1. Control of production via build records per unit
  • Clause 8.7. Nonconforming output via in-line defect flag + disposition
  • Clause 9.1. Monitoring via cycle-time + defect-rate + downtime KPIs
  • Clause 9.2. Internal audit via searchable build history
  • Clause 10.2. Corrective action via attributed approvals + reason text
Get started

Ready to run your line on Ignite Lean?

Free during early access — 1 manager seat included, unlimited operators.

Get early access