Internal audit programme

ISO 22301 Clause 9.2.2 requires you to plan, establish, implement, and maintain an internal audit programme for your BCMS that defines audit frequency, methods, roles, planning, and reporting based on process criticality, organizational changes, and prior audit results ¹. Operationalize it by publishing a risk-based multi-audit schedule, assigning competent independent auditors, and proving closure of findings.

Key takeaways:

• Your audit programme must be risk-based: prioritize critical processes, significant changes, and repeat issues ¹.
• Audits must be planned and repeatable, with clear scope, criteria, methods, independence, and reporting.
• Evidence matters: keep the programme, plans, reports, and corrective action closure records ready for certification and internal assurance.

An “internal audit programme” under ISO 22301 is not a single audit or a calendar reminder. It is a managed system for deciding what gets audited in your business continuity management system (BCMS), when it gets audited, how audits are performed, who performs them, and how results are tracked to closure ¹. Auditors and certifiers look for a programmatic approach that you can defend: why you chose certain areas, why you set a given cadence, and how prior results changed what you audited next.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this like a control framework: define the audit universe (BCMS clauses, processes, sites, critical services), assign risk tiers, publish an audit schedule, standardize audit workpapers, and create a simple workflow for findings and corrective actions. If your organization also manages third parties that support critical products or services, include BCMS dependencies in scope where they materially affect continuity outcomes (for example, outsourced contact center operations or a cloud service required for recovery).

This page gives requirement-level guidance you can implement immediately, with a focus on what evidence you will need to show an auditor.

Regulatory text

Requirement (excerpt): “The organization shall plan, establish, implement and maintain an audit programme.” ¹

Operator interpretation: You must run internal audits as a sustained programme, not ad hoc reviews. The programme must define (at minimum) audit frequency, methods, responsibilities, planning requirements, and reporting. It must also reflect risk and reality: the importance of processes, changes affecting the organization, and results of previous audits should influence what you audit and how often ¹.

Plain-English interpretation (what the requirement is “really asking”)

You need a documented, repeatable approach that answers four questions:

1. What will you audit? (Your BCMS components: governance, BIA, risk assessment, strategies, plans, exercises, incident response interfaces, metrics, management review, etc.)
2. How will you audit it? (Methods and criteria: interviews, sampling, evidence review, site checks, tabletop observation)
3. When and how often? (A schedule that you can justify based on criticality, changes, and past audit results)
4. What happens to issues? (Reporting, escalation, corrective actions, verification of closure)

A mature audit programme produces two outputs you can defend: (a) credible assurance that the BCMS conforms to your own requirements and ISO 22301, and (b) a clear pipeline for improvements.

Who it applies to

Applies to: Any organization operating a BCMS aligned to ISO 22301, including entities pursuing certification or maintaining certification ¹.

Operational context where this gets tested:

• You have multiple sites, business units, or in-scope services and need an audit approach that scales.
• You rely on third parties for critical activities (technology, logistics, call centers, facilities). Your BCMS audit scope should address continuity dependencies where failure would break recovery objectives or response capability.
• You have frequent organizational change (reorgs, migrations, new products) and need the audit programme to adapt rather than stay fixed.

What you actually need to do (step-by-step)

1) Define the BCMS “audit universe”

Create a list of auditable units. Keep it practical:

• BCMS processes: leadership/governance, BIA, risk assessment, strategy, plans, training/awareness, exercising/testing, incident response coordination, performance evaluation, corrective action.
• Business/service scope: critical products/services, supporting functions, key sites.
• Dependencies: major third-party continuity dependencies (only those that materially affect your continuity outcomes).

Deliverable: Audit Universe Register (one table).

2) Set risk-based prioritization rules

Document the factors you will use to set audit frequency and focus. ISO 22301 expects you to consider:

• Importance of processes
• Changes affecting the organization
• Results of previous audits
  ¹

Practical approach:

• Assign each auditable unit a risk tier (for example: high/medium/low) based on criticality and change velocity.
• Add “override triggers” that force an out-of-cycle audit, such as a major incident, a recovery failure, or a significant control change.

Deliverable: Audit Programme Methodology (1–2 pages).

3) Publish the internal audit programme (the master plan)

Your programme should state:

• Scope boundaries (BCMS scope statement alignment)
• Roles and responsibilities (programme owner, lead auditor, auditees, approvers)
• Independence rules (auditors do not audit their own work)
• Competence expectations (training/experience requirements)
• Audit methods (interviews, sampling, evidence review, observation)
• Reporting requirements and timelines (define internal SLAs as your policy, but keep them achievable)
• How findings are tracked and closed (corrective action workflow)

Deliverable: Internal Audit Programme Document (controlled document).

4) Build the audit schedule and individual audit plans

Create a schedule that maps the audit universe to planned audits. For each audit, prepare an audit plan that includes:

• Objective and scope
• Criteria (ISO 22301 clauses, internal policies/standards, BCMS procedures)
• Agenda and stakeholders
• Sampling approach and evidence to be reviewed
• Reporting format and rating approach (if you use one, define it)

Deliverables:

• Audit Schedule
• Audit Plan template + completed plans

5) Execute audits using standardized workpapers

Standardize how auditors collect evidence so results are consistent:

• Opening meeting notes
• Evidence list (documents reviewed, systems checked)
• Interview notes (who, when, what was confirmed)
• Test steps and results (what you checked and what you found)

Deliverable: Audit Workpapers per audit.

6) Report, classify, and route findings

Your audit report should be concise and action-oriented:

• Summary of scope and work performed
• Conformities and good practices (optional, but helpful for buy-in)
• Nonconformities/observations with clear evidence statements
• Corrective action requests with owners and due dates (your internal standard)

Deliverable: Audit Report + Findings Log.

7) Verify corrective actions and update the programme

Closure is part of “maintain the programme.” Track:

• Corrective action plan
• Evidence of remediation
• Verification/validation performed by someone independent of the fix
• Programme updates driven by results (repeat findings should drive more attention) ¹

Deliverables:

• Corrective Action Records
• Closure Verification Notes
• Updated Audit Schedule/Programme when needed

8) Use tooling without losing audit discipline

Most teams fail on follow-through, not on drafting a policy. A system like Daydream can help you manage the audit universe, schedule audits, collect workpapers, and track findings to closure with clear ownership and reminders. Treat the tool as evidence plumbing; your methodology and independence rules still need to be explicit in the programme.

Required evidence and artifacts to retain (exam-ready)

Keep these in a single folder or GRC system with version control:

• Approved Internal Audit Programme document
• Audit universe register and risk tiering rationale
• Audit schedule and any mid-cycle changes (with reasons tied to importance/changes/prior results) ¹
• Per-audit plans, workpapers, evidence lists, and reports
• Auditor competence records (training, experience, qualification)
• Independence/assignment records (who audited what and why it was independent)
• Findings log with status and due dates
• Corrective action documentation, approvals, and verification of closure
• Management review inputs showing audit results were considered (ties into broader ISO 22301 performance evaluation)

Common exam/audit questions and hangups

Auditors commonly probe:

• “Show me the audit programme. How do you decide frequency and scope?”
• “How do you account for organizational changes in the programme?” ¹
• “What happened after the last audit? Show corrective action closure evidence.”
• “How do you ensure auditor independence and competence?”
• “Prove the programme is maintained. Where are updates based on prior audit results?” ¹
• “Do your audits cover the full BCMS scope over time, not just a narrow slice?”

Hangups that delay certification:

• Audit schedule exists, but there is no rationale tied to process importance or change.
• Findings are written as opinions rather than evidence-based statements.
• Corrective actions are “closed” without verification evidence.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Confusing an audit plan with an audit programme.
   Fix: Maintain a master programme that governs all audits, plus separate plans for each audit.

2. Mistake: Auditing only documentation.
   Fix: Include operational proof. Observe an exercise, sample call trees, validate restoration evidence, and check training completion records.

3. Mistake: No mechanism for changes.
   Fix: Define triggers for programme updates when there is a major system migration, reorg, new site, or continuity-impacting incident ¹.

4. Mistake: Lack of independence in small teams.
   Fix: Use cross-functional auditors, second-line staff, or a qualified external resource for areas where the BCMS owner would be self-auditing. Document the approach.

5. Mistake: Findings don’t drive the next cycle.
   Fix: Build a rule: repeat findings elevate scope depth or audit frequency for that area ¹.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for ISO 22301 Clause 9.2.2. Practically, the risk is certification-related and operational: a weak audit programme reduces your ability to detect BCMS gaps before a disruption, and it is a common source of nonconformities during certification and surveillance audits because it is easy to test with document and record review ¹.

Practical execution plan (30/60/90 days)

First 30 days (stand up the programme)

• Confirm BCMS scope and build the audit universe register.
• Draft the internal audit programme document (roles, independence, competence, methods, reporting, corrective action workflow).
• Define risk tiering and change triggers tied to process importance, organizational change, and previous results ¹.
• Select tooling or a simple tracker for schedule + findings (Daydream or an equivalent controlled system).

By 60 days (run audits and prove follow-through)

• Publish the audit schedule and get leadership approval.
• Train internal auditors on the audit method and evidence standards.
• Execute at least one pilot audit using standardized workpapers.
• Issue the audit report, log findings, assign corrective actions, and start remediation tracking.

By 90 days (stabilize and make it repeatable)

• Complete additional audits from the schedule, prioritizing critical processes and areas with significant change.
• Verify closure for the pilot audit’s corrective actions (not just “due date passed”).
• Update the programme/schedule based on results and lessons learned ¹.
• Prepare an “audit readiness pack” folder that contains the programme, schedule, reports, and closure evidence.

Frequently Asked Questions

Do we need a separate internal audit programme for business continuity, or can it be part of the enterprise internal audit plan?

It can be part of an enterprise plan if the BCMS scope is clearly covered and you can show BCMS-specific scheduling, methods, responsibilities, and reporting ¹. The key is being able to demonstrate a maintained programme for the BCMS, not the document title.

How do we show the audit programme is “risk-based” without making it complicated?

Use a simple audit universe register with a few drivers: process criticality, major changes since last audit, and prior findings history ¹. Document the rationale in a short methodology and apply it consistently.

What counts as “maintain” the audit programme?

You maintain it by keeping the schedule current, adjusting audits when there are significant organizational changes, and updating future audit focus based on prior audit results ¹. Evidence is shown through version history, change notes, and updated schedules.

Can the BCMS owner audit their own area if we’re a small organization?

Avoid it where possible because independence is a common audit hangup. If you cannot avoid it, document compensating steps such as peer review of workpapers, independent approval of findings, or use of a qualified external auditor for that scope.

What artifacts do certifiers ask for most often?

The programme document, the schedule, completed audit plans, audit reports, and corrective action closure evidence are the usual first requests. If you can produce those quickly and they show updates driven by change and past results, the audit tends to move faster ¹.

How should third-party dependencies show up in the audit programme?

Include third-party continuity dependencies where failure would materially impact your recovery strategies or response capability. You are not auditing the third party’s entire business; you are auditing how your BCMS manages that dependency (requirements, monitoring, evidence of resilience commitments, and contingency plans).

Footnotes

1. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements