"Audit-ready" gets used loosely enough that it risks becoming decoration. So here is a definition narrow enough to be falsifiable: a system is audit-ready if a competent outsider can verify how it works, who can access what, and what changed when — without asking anyone who built it.

That last clause is the whole test. If the answer to any important question lives only in someone's head, you are not audit-ready. You are dependent.

The eight properties reviewers check

1. Reproducible setup. A new engineer clones the repository and has it running locally in under an hour, from documentation alone.
2. Meaningful test coverage. Not a percentage — coverage specifically around money movement, permissions, and personal data.
3. Access control at the data layer. Authorisation enforced where the data is read, not checked screen by screen in the interface.
4. An audit trail. Who changed what, when. For any record a regulator, customer or court might ask about.
5. Dependency provenance. A complete inventory of third-party code with licences, and a documented process for updating it.
6. Recoverability. Backups that have been restored at least once, with a written recovery time objective someone has actually measured.
7. Written architectural decisions. Not diagrams of what exists — records of what was chosen, what was rejected, and why.
8. No single points of human failure. Nothing in production requires one specific person to be reachable.

Why this is commercial, not technical

Every one of those eight properties converts directly into money at a moment you do not control:

• An enterprise buyer sends a security questionnaire. Audit-ready means you return it in two days instead of two weeks, and you close within the quarter.
• An investor commissions technical due diligence. Audit-ready means the report says "no material findings" instead of a list that becomes a valuation adjustment.
• A key engineer leaves. Audit-ready means a handover instead of an archaeology project.
• An incident happens. Audit-ready means you can say exactly which records were affected — which is often the difference between a notification and a crisis.

None of these are things you can prepare for on demand. By the time the questionnaire arrives, the state of your system is already fixed.

The self-assessment

Run this today. It takes an afternoon and requires no technical skill beyond asking:

• Ask an engineer to set the project up on a fresh machine using only the documentation, and time it.
• Pick one customer record and ask who changed it last, when, and from where. Time the answer.
• Ask when a backup was last restored — not taken, restored.
• Ask which third-party libraries are in the product and under what licences. If this takes more than five minutes, it is not documented.
• Ask what would break if your longest-serving engineer were unreachable for two weeks.

The gaps this reveals are usually small individually and serious in aggregate. Most teams can close them in four to six weeks — but only while nobody is waiting on the answer.

Audit-ready is not a certificate you obtain. It is the property of being able to prove things about your own system on someone else's schedule.

We build every system to this standard by default, because retrofitting it is roughly three times the cost of doing it as you go. If you want an outside read on where your system currently stands, a short audit will give you the eight answers above in writing.