Preparing the Audit: Document Review & Audit Plan

Lesson 3 defined objectives, scope, and criteria. This lesson turns those into two concrete working documents every competent auditor prepares before ever conducting an on-site (or remote) audit activity: a document review and an audit plan.

Why document review comes first

Reviewing an organization's documented information — policies, the SoA, the risk register, prior audit reports, management review minutes — before any on-site activity serves two purposes: it lets the auditor identify whether the documented system, on paper, appears capable of meeting the criteria at all (catching gaps before wasting on-site time), and it lets the auditor prepare specific, targeted questions and evidence requests rather than starting on-site with generic ones. Skipping this step doesn't just waste time — it risks an audit team arriving on-site and discovering, mid-audit, that a foundational document (like the SoA itself) doesn't exist or is badly out of date, which should have been caught and addressed before travel and interview time were committed.

What document review is looking for

Document review isn't about approving or rejecting the system yet — that requires on-site verification. It's about identifying:

• Adequacy — does the documented system, as written, appear capable of meeting the stated criteria? (e.g., does a policy exist for every SoA-applicable control area?)
• Internal consistency — do the risk register, SoA, and policies actually reference each other correctly, or do they contradict each other? (echoing this roadmap's Lesson 1 point about evidence needing to be genuinely traceable)
• Currency — are these documents recently reviewed and version-controlled, or stale artifacts no one has touched since initial drafting?
• Prior findings status — for a surveillance or recertification audit, have previously identified nonconformities been addressed, based on the documentation provided?

A document review that finds the SoA references controls that don't appear anywhere in the risk register — or a risk register with several open High risks that the SoA claims are fully treated — is exactly the kind of internal inconsistency that should shape the on-site audit plan's priorities, not be quietly overlooked until later.

Turning objectives/scope/criteria into an audit plan

The audit plan is where Lesson 3's three parameters become something the audit team can actually execute against: a schedule of specific activities (which processes, interviews, and site areas will be covered and when), named responsibilities within the audit team (if more than one auditor), and logistics (who from the auditee needs to be available, what access or documents are needed in advance). A plan that just restates the scope and criteria without breaking them into a concrete schedule of activities isn't yet a usable plan — it's still just the input to one.

Building the audit checklist

A checklist translates the plan into specific questions and evidence requests, each tied to a criterion. A good checklist item names the specific control or clause, what evidence would satisfy it, and who's likely to have that evidence — for example: "8.16 Monitoring activities — request: SIEM alert review log for the last quarter; likely source: SOC lead." A checklist item that just says "check monitoring" gives the auditor nothing concrete to request, and tends to produce exactly the kind of unverifiable, interview-only finding this roadmap's Lesson 1 already flagged as a violation of the evidence-based approach principle.

The document review's role in re-scoping

Occasionally, document review reveals that the original scope or criteria (Lesson 3) need adjusting before the on-site audit even starts — for example, discovering during document review that a business unit believed to be in-scope was actually divested six months ago. Catching this during document review, and formally updating the audit plan, is far better than discovering it awkwardly on day one on-site with the audit team already deployed.