"Audit-ready" appears on every inspection software datasheet, and it almost never comes with a definition. That makes it decoration. The term does have real content, because audits themselves have real structure: an auditor asks for a record, questions its basis, and tests whether the program's claims about itself are demonstrable. Software either supports that interaction or it does not, and you can test which before buying.
The four properties that constitute audit readiness
- Attribution, complete and durable. Every record answers who: who took the reading, who entered it, who reviewed the report, who approved the interval, who closed the recommendation. Attribution must survive the awkward paths: offline capture on a shared device, bulk imports, migrations, and the departure of the person named. "The admin account" is not an answer an auditor accepts.
- Immutability with corrections, not erasures. Auditors do not expect perfect data. They expect that corrections are visible as corrections. When a reading is amended, the record shows the original value, the new value, who changed it, when, and ideally why. A system that overwrites in place fails this even if nobody ever misuses it, because it cannot demonstrate that nobody did.
- Completeness on demand. The hardest audit questions are negative claims: no vessel is overdue, no recommendation is unowned, no interval lacks a basis. Proving a negative requires structure, an authoritative equipment list joined to inspection events and due dates, queryable live. If demonstrating completeness takes a data export and a week of spreadsheet work, the program is not audit-ready regardless of how good the data is.
- Evidence attached at the point of claim. When the record says the vessel was inspected, the report, the readings, and the photographs open from that record. When a corrosion rate justifies an interval, the readings behind the rate are one step away. The auditor's trust compounds when every drill-down lands on evidence, and evaporates the first time it lands on a broken reference.
What audit-ready is not
Worth naming, because these get sold as the real thing:
- A document repository. Storing signed PDFs is retention, not readiness. The PDF proves a document exists, not that the program is complete or the approval chain intact.
- An access log. Knowing who viewed a record is security telemetry. Audit trail means who changed what, with before and after values.
- A compliance module purchased separately. If attribution and history are add-ons, the core system was designed without them, and bolted-on trails have seams. Ask what the base product records when the module is absent.
- A report formatted like your regulator wants. Output formatting is the easy part. The question is whether the numbers in the report trace to records that survive challenge.
How to test it in a demo
Take twenty minutes of any vendor demo, including ours, and run this sequence. Pick a reading and ask to see its full history, including any correction. Ask who approved the containing report and where that approval is recorded. Ask for the list of overdue inspections, live, and then ask how the system knows the list is complete. Finally, change a value as a test user and ask the vendor to show you the trail your change just left.
A system with these properties makes the audit itself smaller: preparation becomes review, because the assembled state the auditor wants is the system's normal state. That, and not a datasheet adjective, is what audit-ready means.
This definition is the bar we hold intelliSPEC to, and the demo sequence above is one we are happy to run live. Use it on every vendor on your shortlist and the adjective will sort itself into evidence or decoration quickly.
