Audit engagement checklist — a QMS held in KF

One page, for the audit plan. Every item here has to be settled before the opening meeting; none of them can be fixed on the day, and each changes what the findings are worth.

Agreed between: ______________________ (auditor) and ______________________ (auditee), on ____________.

Access

• ☐ Read credentials issued to the auditor, in their own name, for both surfaces: the web app and the AI chat (/mcp). Not shared, not the helper's.
• ☐ The session runs under the audit's own account even when the helper is at the keyboard. The trail records an account, not a person; under a shared account it records nothing useful.
• ☐ The account is read-only. Confirmed by walking the register, an item, the listing and the risk model and seeing no control that would write.
• ☐ Helper named: ______________________. Role recorded as competent intermediary, present at the auditor's discretion — not as the interface to the system.
• ☐ Recorded where the auditor takes it back: the criteria judgement, the cross-reading, and any question whose framing is itself in issue.

The register, before the period opens

• ☐ audit-open.sh prepare run and read out — the dry run, which writes nothing.
• ☐ audit-open.sh snapshot run: register materialised, before- and after-states exported, population exported, SHA256SUMS written.
• ☐ Manifest hash recorded by both parties: ________________________________
• ☐ Understood why: a finding can only attach to a requirement the organization has taken on, so raising one on an inherited row moves it from missing to pending. Materialising up front is what stops the register improving because it was audited.
• ☐ Drift report to be run at the close (audit-open.sh drift ), and any change during the period accounted for.

Criteria

• ☐ Requirement library version fixed and recorded: config_uid ________________________ , dated ____________.
• ☐ Any edit to the library during the audit period is itself a finding. Agreed in writing.
• ☐ Library validation against the standard is current and was done separately — audit-criteria-validation.md. Date: ____________.
• ☐ Standing scope limitation from that validation carried into the report. Clauses not assessed: ______________________________.

Provenance

• ☐ KF build and pack provenance captured at the open, from the page footer or /api/provenance, and pasted into the working papers.
• ☐ The version-dependent behaviours table (§8 of audit-for-auditors.md) checked against that build, so the counts quoted in the report are known to be counts of the same thing.

Records of the audit itself

• ☐ Transcript retention agreed in writing: who keeps the chat transcript, for how long, in what form the certification body may have it. Held by: ______________________ for ________.
• ☐ Session trail exported at the close (/api/audit-trail?format=csv&user=&since=) and filed.
• ☐ Understood that the trail records routes, tools, arguments and sizes — not record content. If the certification body needs the evidence examined and not only the coverage, that is a different retention decision, taken here.

Confidentiality

• ☐ Where the AI model runs, who operates it, and what it retains: ____________
• ☐ Agreed that the auditee's records — document bodies included — pass through it.
• ☐ Agreed position on the auditor's line of questioning: a transcript held on the auditee's instance shows them which requirements were probed, in what order, and where the auditor went back for a second look. Either the transcript is held by the auditor, or this is accepted explicitly.
• ☐ Deletion obligations and dates recorded.

Evidence outside KF

• ☐ Identified up front, with a conventional evidence route agreed for each:

Evidence held outside KF	Where	How it will be examined
Sibling legal entity records
Shared drives
Email
Paper

• ☐ Understood that the two evidence sets are planned in parallel, not reconciled afterwards. The AI channel adds workload before it saves any.

Method commitments

• ☐ Verification rule accepted: re-reading the record in the app is mandatory for every claim that becomes a finding (including negative findings), every done row in the sample, every load-bearing date, and every count to be quoted.
• ☐ Stopping rule accepted: every missing row chased by subject search before write-up; a full evidence walk on every release-critical, customer-facing or previously-cited requirement; a sample of the remainder drawn from a stated listing with its total; and one re-derived risk rating, one revision diff and one cross-read on the record as method checks.
• ☐ Time budgeted for the cross-read — half a day for a small QMS. It is the step that produces the findings that matter and the one nothing automates.

*Companions: audit-for-auditors.md, audit-for-helpers.md,

audit-criteria-validation.md.*