ISO 9001:2026: Your Access Calibration DB Is a 6.1 Risk

Rebuilding your clause 6.1 risk register for ISO 9001:2026? The Access file behind every calibration due date belongs on it. Here's a worked entry.

October 5, 2026 8 min read 1,404 words

Picture Katrin, Quality Engineer at a mid-sized automotive supplier. The ISO 9001:2026 gap-analysis kickoff is on the calendar. She opens the risk register to restructure it and finds what she expected: supplier single-sourcing, a key press line with no spare spindle, cybersecurity on the ERP, staff turnover in the paint shop. All of it is reasonable and all of it has an owner.

Nowhere does it mention the .accdb file on a shared drive that every calibration due date in the plant comes from.

That isn’t negligence. The database has been running so long that nobody sees it anymore. This article argues that the 2026 transition is the right moment to make it visible again, and shows what an honest register entry for it looks like.

Why the database never made it onto the register

Most homegrown calibration databases were built for good reasons. A capable engineer saw spreadsheets failing, IT had no budget for a dedicated tool, and Access was already installed. It worked. One practitioner who built one put it plainly on a long-running quality forum: "I have been audited a number of times and have never had a question raised."

That is true for many plants, and it is exactly why the database stays off the register. Registers collect things that feel uncertain, and something that has passed every audit doesn’t feel uncertain. But passing audits tells you how the system has performed so far. It doesn’t tell you whether the conditions that kept it working are still there: the person who understands the VBA, the Office build it was tested on, the file size it was designed for.

What ISO 9001:2026 changes, and what it doesn’t

ISO 9001:2026 was published on 16 September 2026. The transition deadline falls around the end of September 2029, and the first certificates against the new edition are expected from roughly Q3 2027. Gap analyses are starting across the industry now.

Here is the part that matters for this argument. In the summaries published so far, clause 6.1 is restructured into 6.1.1 to 6.1.3, which separates actions on risks from actions on opportunities. Clause 7.1.5, on monitoring and measuring resources, shows no material change. The requirement for measurement traceability and calibration isn’t new. What’s new is the occasion: almost every certified organisation will rebuild or at least re-examine its risk register over the next 12 to 24 months.

That rebuild is the cheapest moment to add an entry. Nobody has to justify reopening a document that is already open. And a risk entered during the transition can be reviewed alongside the rest of the register, instead of turning up later as a surprise.

Why it qualifies as a risk, in specifics

A risk entry has to be concrete or it won’t survive review. "Legacy software is risky" won’t do. These causes will hold up:

Silent overwrites. When two people edit the same record, Access shows a Write Conflict dialog. Microsoft’s own help text says that choosing "Save Record" can overwrite the other person’s changes, and that "the other person most likely loses their changes." In a calibration database, that means one technician’s as-found result can replace another’s, and nothing records that it happened.
Engine defects in the patch stream. Access is actively maintained, which is good. But the 2026 fix logs include defects that touch calibration logic directly. Version 2604 fixed a Long Text field corrupting when a query updated a record while someone was editing it. Version 2606 fixed a query with an IS NULL predicate returning incorrect data. Overdue queries often rely on Is Null (no return date, no last calibration date), and remarks usually live in Long Text fields. Whether a given PC has the fix depends on its update channel and build.
A capacity ceiling you can forecast. An Access file is limited to 2 GB including system objects, and performance degrades well before that, from around 1.5 GB. At the limit the errors are blunt: "Cannot update. Database or object is read-only." Embedded certificates make the file grow faster.
Two records, no declared master. In many plants technicians still write results in a binder and someone keys them in later. In the same forum one engineer described it this way: "we run into problems where the 2 do not match."
A single point of knowledge. If one person maintains the VBA, the program’s continuity depends on that person’s employment.

Each of these leads straight to the outcome 7.1.5 exists to prevent: a measuring instrument used while overdue or out of tolerance, without the organisation knowing.

A worked register entry

This is what an entry could look like. Adapt the scoring scale to your own method.

Notice that the treatment has two layers. Interim controls cut the risk this quarter: test a restore, check Office builds on the PCs that touch the file, reconcile the binder monthly, track file size, and train a second person. Migration is the treatment that actually removes the causes, and the register gives it a date and an owner instead of a "someday".

The objection: "Writing it down invites the auditor to ask"

This is the most common reason the entry never gets made, and it has the logic backwards. Clause 6.1 asks you to determine risks and plan actions to address them. A documented risk with an owner, interim controls and a dated treatment plan is evidence that your system is working. A database weakness the auditor discovers on their own, during a sample trace that won’t reconcile, is a finding.

The second objection is usually about hosted systems: "I wouldn’t be comfortable having my documentation stored somewhere by someone." That is fair, and it belongs in the treatment plan as a requirement, not a reason to wait. Write down what you need on data ownership, export, retention and tenant isolation, and judge any replacement against that.

What the migration treatment looks like

A staged migration keeps history and traceability intact:

Export every table, including retired instruments and attached certificates.
Clean duplicates, orphaned results and inconsistent IDs, and decide which record is master wherever the binder and the database disagree.
Map fields to the new structure: instrument type, interval, as-found/as-left, tolerance, location, holder.
Validate by reconciling due dates and last results for the whole population, not a spot sample.
Run in parallel for one full due-date cycle, then retire the Access file to read-only archive.

In PrüfDesk, the team gets these on day one:

Calibration due dates calculated automatically from the interval.
Pass/fail records with certificates attached.
As-found/as-left logging.
Reusable procedure templates that apply across an instrument type and can be overridden per unit.
Configurable overdue blocking, set per tenant as either a hard block or a soft warning.
A full check-out and allocation trail.
Audit-ready PDF compliance reports.

Each of those closes one of the causes listed in the register entry above.

Pre-migration checklist

[ ] Risk entry added to the 6.1 register, with owner and review date
[ ] Backup restore tested and the test recorded
[ ] Office/Access build recorded for every PC that touches the file
[ ] Current file size and its growth over the last 12 months noted
[ ] Binder and database master declared in writing
[ ] A second person able to explain the overdue logic
[ ] Data ownership, export and retention requirements written down
[ ] Migration window chosen, avoiding the year-end shutdown crunch

A sensible next step

You don’t have to decide on a system this week. Add the entry, run the interim controls, and let the register set the pace. When you’re ready to look at the migration treatment, PrüfDesk can walk through your current database structure with you and show you how your history would map across.