4.3 Developing a Risk-Based Audit Plan and Checklist

4.3 Developing a Risk-Based Audit Plan and Checklist

After objectives, scope, and criteria are set and the team is competent, the lead auditor converts strategy into an audit plan and supporting working documents. ISO 19011 expects planning that considers risks to achieving the audit objectives—and for ISMS audits that also means using a risk-based lens on where to spend scarce audit hours inside the organization's information security landscape.

This section separates risks to the audit from information security risks that drive sampling, then shows how to construct a usable plan and checklist without turning the audit into a rigid script.

---

Two Risk Conversations Lead Auditors Must Keep Distinct

Confusing the two produces odd plans: either an obsessively logistical schedule that samples only low-value areas, or a technically ambitious itinerary that collapses when access and people are not arranged.

---

Identifying and Mitigating Risks to Audit Execution

Before locking the timetable, identify execution risks and mitigations:

• People access: CISO, process owners, and administrators booked with named deputies
• Physical / logical access: clearances for data halls, badge escorts, break-glass for evidence portals, agreed screen-sharing rules for remote audits
• Information availability: SoA version, risk assessment outputs, policies, and sample populations staged before Day 1
• Technology for remote auditing: test platforms, recording rules (often restricted), time-zone overlap
• Competence continuity: backup auditor briefed if a specialist becomes unavailable
• Scope complexity underestimation: multi-site travel buffers; parallel audit streams only when coordination is planned

Document mitigations in planning notes even if the client-facing plan stays concise. A plan that assumes perfect availability is not risk-based—it is hopeful.

---

Risk-Based Emphasis Inside the ISMS

A risk-based approach to planning allocates more time and stronger sampling to areas with higher likelihood of nonconformity or higher impact on information security outcomes—while still ensuring adequate coverage of the audit criteria overall.

Inputs That Shape Emphasis

Lead auditors typically review:

1. Previous audit results — recurring issues, open nonconformities, weak management review follow-up
2. Organization's risk assessment and treatment — high residual risks, newly treated risks, disputed risk acceptance
3. SoA — newly applicable controls, controls marked implemented with limited operating history, complex exclusions
4. Significant changes — reorganizations, new products, cloud exits/entries, major incidents since the last audit
5. External context — new regulatory obligations the organization has identified as applicable, sector threats
6. Performance indicators — incident trends, exception rates, privileged access growth (as available)

Example Emphasis Decisions

• Stable visitor badge process with clean history → lighter sampling
• Privileged access to production after a devops reorganization → deeper sampling of joiner-mover-leaver, MFA, logging, and approvals
• Supplier hosting personal data → deeper review of supplier due diligence, contractual security requirements, and monitoring
• Annex A themes claimed applicable for cryptography after a key-management redesign → technical verification with competent team members

Risk-based planning does not mean ignoring low-risk areas entirely when criteria require coverage; it means proportional effort. Certification and competent internal programs still need a cycle strategy so that over time all relevant processes and sites receive appropriate attention.

---

Constructing the Detailed Audit Plan

The audit plan coordinates the engagement and is communicated as appropriate to the audit team and auditee. Typical contents include:

• Audit objectives, scope, and criteria (consistent with Section 4.1)
• Dates, locations, and remote/on-site mode
• Schedule of activities and expected durations, including opening and closing meetings
• Audit team roles, technical experts, guides, and observers
• Allocation of high-emphasis areas to named auditors
• Working language and logistics notes that affect feasibility

A Workable Daily Structure (Illustrative)

Plans should allow controlled flexibility: if evidence reveals a significant unidentified issue in identity management, the lead auditor may shift time from a lower-risk area—while still protecting minimum coverage needed for the objectives and documenting the change rationale.

Sampling Without False Precision

ISMS audits rarely examine every record. Planning should define sampling approaches appropriate to the process (for example, recent change tickets, privileged accounts created in the last quarter, incident records above a severity threshold). Avoid inventing rigid "pass rates" or percentage thresholds that standards do not prescribe for auditor judgment. Explain sampling logic in working papers so conclusions remain defensible.

---

Checklists and Other Working Documents

Working documents help auditors perform the plan consistently. The most common is the audit checklist or aide-mémoire linked to criteria.

What a Strong ISMS Checklist Contains

• References to ISO/IEC 27001 clause requirements and relevant SoA control themes for the time slot
• Prompts for what to look at (documented information, records, technical settings) and whom to ask
• Space to record evidence identifiers (document IDs, versions, ticket numbers, system names, interviewee roles)
• Open-ended probes, not only yes/no boxes

Weak prompt: "Access control policy exists? Yes/No."

Stronger prompt: "Examine the access control policy and operating procedure. How are joiner-mover-leaver events triggered? Sample recent privileged account changes; verify approvals and review evidence against SoA claims for access control. Record system name, sample IDs, and any discrepancies."

Checklist Discipline Without Tunnel Vision

Checklists support:

• Coverage of mandatory criteria themes for the visit
• Time management during interviews
• Traceability from evidence to later findings and reports

Checklists must not:

• Replace professional inquiry when unexpected evidence appears (for example, unprotected sensitive printouts noticed while walking to a meeting)
• Become so long that the auditor reads questions without listening
• Be treated as confidential "gotcha" scripts withheld for gamesmanship—auditing remains a systematic, fair process

Other working documents may include sampling sheets, evidence logs, and confidential notes handled per agreement with the client and auditee.

---

Integrating SoA and Annex A / ISO/IEC 27002 Thinking into the Plan

When building the plan and checklist:

• Use the SoA to select which control themes appear on which day
• Use ISO/IEC 27002 as guidance for what effective implementation often looks like—without treating every 27002 recommendation as a mandatory criterion unless the organization's ISMS makes it so
• Cross-check that high residual risks in the risk treatment plan have corresponding planned audit attention
• Ensure exclusions in the SoA are scheduled for justification review, not silently accepted

Planning Quality Checklist for the Lead Auditor

Before issuing the plan, confirm:

1. Objectives, scope, and criteria on the plan match the agreed engagement
2. High-risk ISMS themes have explicit time and competent auditors
3. Execution risks have mitigations (access, people, tools)
4. Checklists reference SoA version/date used for preparation
5. Flexibility and escalation paths exist if significant issues emerge
6. Confidentiality and information-handling rules are understood by the team

A risk-based plan plus thoughtful working documents enables the team to evaluate the ISMS efficiently, focus on what matters to information security, and still remain open to evidence that the checklist author did not anticipate.