13.3 Writing the Audit Report
Key Takeaways
- The audit report is the durable record of objectives, scope, criteria, findings, conclusions, team, and dates—not an informal email summary.
- Findings must remain clear with evidence references so verification and certification review can reconstruct the judgment, and a quality review by someone outside the audit team checks traceability, severity consistency, scope accuracy, and defensible language before issue — ISO/IEC 17021-1 separately requires the certification decision to be reviewed by person(s) not involved in the audit.
- Distribution control protects confidential AI, security, and personal data while meeting contractual and CB requirements, and audit records — working papers, evidence, checklists, nonconformity reports — need integrity, availability, and confidentiality for the whole retention period, stored in the certification body's system, redacted at collection, and covered by confidentiality undertakings that outlive the audit.
- AIMS reports should identify AI systems sampled, high-risk observations, and control themes—not only clause numbers in isolation.
- Timelines for draft/final issue must match the audit plan and CB procedure so corrective action and decisions are not delayed.
13.3 Writing the Audit Report
Auditor focus: If it is not in the report (or controlled annexes), it did not officially happen for certification and follow-up. Working notes feed the report; the report feeds decisions.
Why the report matters
The audit report is the formal output of the audit. It enables:
- Auditee corrective action and management review
- CB independent certification review and decision
- Surveillance planning and trend analysis over the certification cycle
- Defensibility if findings are later challenged
ISO 19011 expects reporting of results; CB schemes under ISO/IEC 17021-1 require documented audit conclusions sufficient for decision-making. Informal slide decks used at closing are not a substitute for the controlled report.
Required report content (core set)
Exact templates vary by CB and internal audit procedure, but a complete AIMS audit report typically includes:
| Content block | What to include |
|---|---|
| Identification | Client, sites/virtual environments, report ID, version, classification |
| Audit type | Initial Stage 1/2, surveillance, recertification, special, internal, supplier |
| Objectives | As planned (conformity, effectiveness, legal/contractual interfaces if in scope) |
| Scope | Organizational units, AI systems/services, locations, exclusions and justification |
| Criteria | ISO/IEC 42001 (edition), applicable Annex A / SoA decisions, AIMS docs, other agreed requirements |
| Audit team | Lead auditor, team members, technical experts, observers; competence notes if required |
| Dates & schedule | Audit period, on-site/hybrid days, report date |
| Methods & sampling | Interviews, observation, document review; sampling approach and limitations |
| Findings | Majors, minors, OFIs; each with requirement, evidence, statement |
| Conclusions | Overall judgment vs objectives; effectiveness comments |
| Recommendation | Certification-related recommendation (CB audits) with CB-decision disclaimer |
| Unresolved issues / limitations | Access denials, unavailable systems, pending evidence |
| Follow-up | CA expectations, verification approach |
| Distribution | Controlled list |
| Annexes | Attendance, detailed evidence logs if used, confidentiality notes |
Consistency with the closing meeting
The written report must not invent new majors that were never raised (except rare late-emerging evidence handled under CB rules with auditee notification). Likewise, do not quietly drop majors after closing without documented correction of error. Closing and report tell the same story with more complete written detail in the report.
Clarity and evidence references
Write for a reader who has not seen the dashboards:
- Prefer system IDs, ticket numbers, document titles/versions, dates, interviewee roles (names per privacy rules).
- Link each NC to criteria references (clause, control, procedure ID).
- Keep statements atomic: one primary failure mode per NC unless a structured multi-part NC is intentional and clear.
- Use appendices for long evidence tables rather than burying the conclusion in prose.
Weak vs strong excerpt
| Weak | Strong |
|---|---|
| “Monitoring is poor for AI.” | “Criterion: Procedure MON-AI-02 §5 requires drift alerts with owner and ticket for production ranking models. Evidence: For model rank-prod-v7, dashboard has no drift signal configured; last 90 days show no related tickets; owner interview 2026-05-14 confirmed no drift monitoring in production. NC: Production ranking model operated without required drift monitoring.” |
AIMS-specific sections worth making explicit
Generic MS report shells miss AI substance. Add or expand:
1. AI systems sampled
Table format works well:
| System / model ID | Purpose / impact tier | Lifecycle stage | Key controls sampled | Result theme |
|---|---|---|---|---|
| credit-dec-v3 | High — credit decisioning | Production | Impact assessment, human oversight logs, fairness eval, release gate | … |
| support-bot-api | Medium — customer assist | Production | Transparency notices, third-party terms, use instructions | … |
| recsys-exp-12 | Experimental | Pre-prod (in scope?) | Scope confirmation | Out of / in scope note |
This table supports risk-based credibility: reviewers see you did not only audit the training policy binder.
2. High-risk observations
Summarize themes that cut across findings—even if graded separately:
- Impact assessment completeness vs actual use changes
- Third-party / foundation model residual risk acceptance
- Human oversight effectiveness under operational pressure
- Data lineage and quality controls for training/fine-tuning
- Monitoring and incident learning for model failures
- Transparency and user information for in-scope interfaces
Where AIMS is integrated with ISMS/QMS, note shared processes tested and boundaries (AIMS-only vs joint).
Distribution control and confidentiality
AI audit reports may contain security/abuse-risk detail, sensitive bias results, proprietary performance cues, and personal data if evidence was poorly redacted. Controls: classification marking, a named distribution list, redaction of unnecessary secrets (detail in restricted annexes if needed), secure transfer/storage per CB and client rules, and the opening-meeting evidence-handling agreements still applied to report artifacts. Never paste full training datasets, raw weights, or unrestricted production logs into a widely emailed PDF.
Timelines and quality before issue
Agree timelines in the plan and confirm at closing: draft (if used) soon after fieldwork for factual check; final report within the CB window; CA plans per major/minor rules (Section 13.4). Late reports delay decisions; rushed error-filled reports destroy trust—budget writing time into the plan.
Protecting Audit Records: Integrity, Availability, Confidentiality
The report is one audit record among many. Working papers, interview notes, sampled evidence, checklists, the audit plan, nonconformity reports, and corrective-action correspondence together form the record that justifies a certification decision — and that an accreditation body may later inspect.
| Property | What it requires | Failure you will actually see |
|---|---|---|
| Integrity | Records are complete and not altered after the fact; changes are versioned and attributable; findings match the evidence they cite | Working papers "tidied up" after the closing meeting so they agree with a softened report |
| Availability | Records are retrievable for the full retention period by everyone entitled to them — surveillance teams, the certification decision reviewer, appeal panels, accreditation assessors | Evidence held only on a departed auditor's laptop, or in a personal cloud account |
| Confidentiality | Access is limited to those with a need to know; auditee intellectual property, personal data, and security detail are protected in transit and at rest | Sampled training data or production logs left in a shared drive with open permissions |
Practical controls: classify and label records at creation; store them in the certification body's system rather than personal storage; redact personal data and secrets when you collect them rather than when you distribute them; apply the retention period the CB and applicable law require; and remove local copies when the engagement closes. The confidentiality undertakings agreed at the opening meeting continue to bind you after the audit ends — including the fact that a nonconformity was raised at all.
AIMS-specific exposure: AI evidence is unusually sensitive. Prompt logs and inference records may contain personal data the auditee itself has not classified; evaluation datasets may be licensed; slice-performance results are commercially damaging if leaked. Prefer to record identifiers and observations in working papers — model version, dataset ID, record count, what you saw — over copying the underlying artifacts.
Quality Review of Audit Documentation
Before the report is issued, someone other than its author reviews the audit documentation. In a certification body this is a defined step, and ISO/IEC 17021-1 requires the certification decision to rest on a review by person(s) not involved in the audit.
| The reviewer asks | Looking for |
|---|---|
| Is every finding traceable? | Requirement cited, objective evidence referenced, statement of nonconformity, grade |
| Do objectives, scope, and criteria match the plan? | No silent scope drift between plan, fieldwork, and report |
| Is severity consistent? | The same evidence pattern graded the same way across systems and across audits |
| Do the conclusions follow the findings? | No clean conclusion sitting above a major nonconformity; no finding list without an overall effectiveness judgment |
| Is the AI systems sampled section accurate? | Systems, versions, and sites match what was really examined |
| Are the working papers complete? | Checklists closed out, sample identifiers recorded, unresolved issues visible rather than quietly dropped |
| Is the language defensible? | Facts not opinions; no consulting recommendations; no promise of a certificate |
Quality review is also how an audit programme detects auditor drift — one team leader routinely grading systemic gaps as minor, another writing opportunities for improvement as nonconformities. Review outcomes feed the programme's monitoring and each auditor's competence evaluation (Chapter 14), which is why the review is recorded rather than done informally over a coffee.
Common AIMS report failures: ISMS clones with no system names; finding dumps without overall effectiveness judgment; evidence-free majors; OFIs written as NCs (or the reverse); scope fog; unbounded distribution. A complete report records what was audited, what failed against which requirement, overall conclusions, and who may see the results—on a timeline that supports action.
Which set best matches core content expected in an ISO/IEC 42001 management-system audit report?
Why should an AIMS audit report include an explicit summary of AI systems sampled?
After the closing meeting, the lead auditor discovers a wording error that overstated a minor as a major. What is appropriate report practice?
Which distribution practice best protects confidentiality of AIMS audit results?
After the closing meeting, an audit team leader softens the wording of a major nonconformity in the draft report and edits the corresponding working paper so the two documents agree. Which audit-record property has been breached, and why does it matter?