ProAuditMap

How to write an IT audit program: six steps to a reliable audit.

A good audit program decides what is tested, against what, and which evidence is enough before the first document arrives. Here is how to proceed, with an example of an audit step.

As of 4 November 2026

Summary

An IT audit program translates the audit objective into individual audit steps. A step names the criterion, procedure, evidence and responsible auditor; you record risk and sample size per step or per audit area. Six stages work well: preliminary scope, risks, criteria, procedures, evidence with sampling, approval. The Global Internal Audit Standards cover planning in Standards 13.2 to 13.6.

What an audit program is and is not

The audit plan describes the audit as a whole: reason, objective, scope, team and dates. The audit program describes the work: which steps show whether the controls are effective? A list of questions is not yet an audit program, because it does not say what an answer is measured against or which evidence is enough.

The Global Internal Audit Standards cover engagement planning in the standards on risk assessment (13.2), objectives and scope (13.3), evaluation criteria (13.4), resources (13.5) and the documented work program (13.6). They do not prescribe a rigid order; the activities overlap. According to them, the work program also names methodologies and tools and the auditors assigned to each task [1].

The six stages

The stages build on each other. Starting directly with procedures often means testing what is easy to test instead of what is risky.

  1. Set a preliminary objective and scope. Phrase the objective as a testable statement, such as “Critical security updates are installed on servers on time”. Name systems, locations and period, and write down what is explicitly excluded. Refine both after the risk assessment.
  2. Describe the risks. What can go wrong and what would the consequence be? Draw on interviews, earlier findings, incidents and known changes. You may deliberately leave out low-impact risks if you document why.
  3. Choose criteria. What defines the target state? Options include internal policies, contracts, laws such as the German BSI Act or DORA and standards such as ISO/IEC 27001. If a criterion is missing or inadequate, clarify before the audit with senior management or the board what applies, and involve the audited area [1].
  4. Derive procedures. First test whether the control is designed properly, then whether it operated during the period. Prefer reperformance and system analysis over inquiry alone.
  5. Define evidence and sampling. Decide in advance which document or analysis is enough. Check whether the whole population can be analyzed. Otherwise plan a sample with a defined population, confidence and tolerable deviation [1] [2]. The sample size calculator gives you the extent.
  6. Plan effort and approve. Estimate auditor days per audit area and compare the total with the time available. If it does not fit, agree additional capacity or a justified reduction with the chief audit executive. If a significant risk then stays untested, raise it with management and in the report. The chief audit executive approves the program before fieldwork, and later changes too [1].

Example: an audit step on patch management

Risk: Known vulnerabilities stay open and are exploited. Criterion: The internal policy requires critical updates to be installed within a defined period. Procedure: Reconcile the patch system with the inventory so that no server is missing. Build the population from all combinations of critical update and affected server during the period, analyze it fully or draw a sample, and compare release and installation for each item. Extent: Full analysis, otherwise a sample with defined confidence and tolerable deviation. Evidence: Patch system report, inventory and change tickets. Responsible: Named auditor. Result: Number of late installations and their cause.

This shows the difference from the question “Is there a patch process?”. The step says what counts as a deviation, and a second auditor could reach the same conclusion traceably. Our samples contain the criterion, procedure and evidence; your team adds risk, sample size and responsibility. See the patch and vulnerability management sample and the overview of sample audit programs.

Common mistakes

These points tend to surface in quality review or, at the latest, when discussing the draft report.

  1. No criterion. Without a target state, the result is an opinion rather than a finding.
  2. Design only, no effectiveness. An approved policy does not show that it is followed.
  3. Population not checked. A sample from an incomplete list says nothing about the missing items [2].
  4. Too many audit steps. An adopted catalog of a hundred questions eats up auditor days. Remove what does not address the risk and record why.
  5. Program not updated. If the scope changes, change the program and get it approved.

Template, spreadsheet or software?

A spreadsheet is enough to start. Once several people work together and evidence, versions and findings need to stay connected, it becomes laborious. The arguments are in the comparison of Excel and Word with software. The audit plan generator gives a first draft of which topics come first next year.

The sample package shows a possible result with audit program, document requests, interviews and report template, without an account. ProAuditMap creates such a package for your topic, and your team reviews, completes and releases it.

NIS2 and DORA scope check

Sources

  1. The IIA, Global Internal Audit Standards (2024), Standards 13.2 to 13.6: https://www.theiia.org/en/standards/2024-standards/global-internal-audit-standards/
  2. ISA 530 Audit Sampling, Ireland edition, October 2022 (IAASA), a financial statement audit standard used here for its method: https://iaasa.ie/wp-content/uploads/2022/11/ISA-530_Oct_2022.pdf

This article describes an established approach and is not legal advice. Your organization’s requirements and the applicable standards prevail.