5.2 Preparing Audit Checklists and Working Documents
Key Takeaways
- Working documents (checklists, sampling plans, evidence forms, attendance records) structure coverage, time use, and the audit trail under ISO 19011 guidance.
- Effective Stage 2 checklists are customized from Stage 1 outputs—especially risk results, SoA decisions, and process criticality—not generic clause-by-clause yes/no lists.
- Judgment-based sampling selects high-relevance items using auditor competence; the plan must be documented and justifiable.
- Working papers must record verifiable evidence details and be protected as confidential information.
Exam relevance
Conducting-the-audit questions frequently probe how Lead Auditors prepare to gather evidence: what belongs in working documents, how checklists should be built after Stage 1, and how sampling supports conclusions without pretending to examine every record. ISO 19011 expects auditors to prepare working documents that facilitate the audit and capture necessary information systematically. For third-party certification audits, ISO/IEC 17021-1 expects the certification body to plan and execute audits so conclusions are based on sufficient appropriate evidence—preparation quality is part of that professionalism.
Core rules: what working documents are for
Working documents commonly include:
- Audit checklists or aide-memoires mapped to processes, clauses, and SoA controls
- Sampling plans (what, how many, selection method, justification)
- Forms or notes templates for recording evidence, findings, and attendance
- Team assignment matrices and daily time boxes linked to the audit plan
Their purposes are coverage (entire agreed scope), consistency (comparable evidence across team members), time management (risk-based allocation), and defensibility (traceable support for findings and certification recommendations).
| Working document | Primary use | Failure mode if weak |
|---|---|---|
| Customized checklist | Drive process-oriented inquiry | Generic yes/no misses implementation gaps |
| Sampling plan | Justify which records/people/systems are examined | Unexplained cherry-picking or over-claiming |
| Evidence notes | Capture verifiable facts | Vague opinions cannot support nonconformities |
| Team assignment sheet | Prevent overlap/gaps across auditors | Duplicate interviews; missed critical processes |
Designing checklists from Stage 1—not from a photocopy of the standard
A Lead Auditor does not treat ISO/IEC 27001 clauses as a static questionnaire. Stage 1 outputs should drive customization:
- Map high residual risks and critical assets to processes and Annex A controls claimed in the SoA.
- Convert requirements into process questions ("Show how terminated contractor access is revoked and verified") rather than existence questions ("Do you have an access control policy?").
- Leave space for interviewee names, document IDs, versions, dates, system names, and observations.
- Include open trails (for example, "Trace one recent security incident from detection to closure").
- Keep the checklist a guide: pursue new trails when evidence suggests systemic weakness.
Good prompt examples:
- "Select three SoA controls marked implemented for remote access; request configuration evidence and recent access reviews."
- "For the last two change tickets affecting production, verify security testing, approval, and rollback considerations."
- "Compare supplier security requirements in contracts with monitoring evidence for one critical cloud provider."
Sampling plans: judgment-based versus statistical
| Approach | Basis | Typical ISMS use |
|---|---|---|
| Judgment-based sampling | Auditor knowledge, risk, prior findings, criticality | Most Stage 2 ISMS audits |
| Statistical sampling | Random selection aiming at defined confidence about a population | Less common; used when large homogeneous populations and method is justified |
When documenting judgment-based samples, state why the selected items matter (highest risk systems, recent incidents, prior nonconformities, outsourced interfaces). If 15 of 500 servers are reviewed for patching, record the selection rationale—criticality tiers, internet exposure, prior failures—not merely the count.
Scenario: transforming Stage 1 into working papers
Stage 1 at a healthcare software firm flagged: (a) SoA exclusions for cryptography controls with thin justification, (b) internal audits that never sampled supplier onboarding, and (c) frequent contractor turnover in development. The Lead Auditor builds Stage 2 working documents that allocate extra time to cryptographic key management evidence, supplier due-diligence records, and joiner-mover-leaver samples for contractors. The checklist includes a trail: "Pick two contractors who left in the last quarter; verify account disablement timestamps against policy." At the daily team meeting, one auditor's notes on missing disablement evidence and another's notes on incomplete supplier questionnaires are combined—suggesting a systemic third-party and identity lifecycle weakness rather than two isolated slips.
Team coordination through shared working documents
On multi-auditor engagements, working documents prevent both duplication and silent gaps. A responsibility matrix should assign processes (identity lifecycle, change management, supplier security, incident response, physical security, business continuity) to named auditors with timeboxes. Daily wrap-ups then cross-read notes: the same missing access review in HR and IT is no longer two minor local issues—it may be a systemic control failure. Standardization also helps the Lead Auditor synthesize a single report without reconciling incompatible note styles.
Practical team rules:
- Agree abbreviations and mandatory fields (who, what record, when, result, follow-up trail) before day one
- Flag "parked trails" that another auditor should pick up
- Escalate potential majors early so the Lead Auditor can adjust sampling the same day
- Never leave the only copy of sensitive notes on an unsecured USB stick or personal email
Recording and protecting evidence
Unacceptable note: "Access control looks fine."
Acceptable note: "Reviewed HR-AC-09 access review for payroll DB dated 15 Oct; three leavers revoked within 24h per IS-04; sampled user IDs L-441, L-442, L-449."
Specificity lets the auditee locate records, supports nonconformity presentation, and allows peer or certification-body review. Because working papers may contain vulnerability data, incident details, and architecture notes, protect them under confidentiality agreements: control distribution, secure storage/transfer, and retention or disposal per certification-body procedures.
Scenario: when the checklist must bend
An auditor following a change-management checklist discovers that emergency changes bypass the documented approval path and that related incident tickets show repeated outages after hotfixes. The checklist did not originally include emergency-change sampling, but professional judgment requires expanding the sample and tracing linkage between emergency changes, post-implementation review, and corrective action. Working documents are updated in real time; the sampling plan justification is annotated. Rigidity would have missed a high-risk process failure; flexibility without notes would have left an undefendable finding. The discipline is: follow the trail, then record why the plan changed.
Prepared well, checklists and working documents are the bridge from Stage 1 intelligence to Stage 2 conclusions—structured enough for coverage, flexible enough for professional judgment, and precise enough to defend findings.
Which description best matches an effective Stage 2 ISMS audit checklist?
Why must auditors record specific identifiers (document numbers, dates, system or user IDs) in working documents?
When using judgment-based sampling in an ISMS Stage 2 audit, what does the auditor primarily rely on?