Category: Audit Process

Audit Program

Also known as: Audit Programme, Audit Plan

Simply put

An audit program is a structured plan that lays out the objectives, scope, timeline, and specific steps an auditor will follow when examining an organization. It helps ensure the audit is organized around relevant risk areas and covers the procedures and tests needed to reach a conclusion. In a compliance context, it guides the work performed but does not itself guarantee any particular outcome, which depends on what is actually tested and observed.

Formal definition

An audit program is a documented framework of audit objectives, scope, timeline, and planned procedures that directs how auditors examine an organization's records, processes, or controls. Development typically begins with research and objective-setting, identification of relevant risk areas, and definition of the tests and activities to be performed. In practice, the specific procedures, sampling, and depth of testing are tailored to the engagement scope and the applicable criteria, so the program's content and rigor vary by auditor and objective rather than following a single fixed template.

Why it matters

An audit program is the backbone of a defensible, repeatable examination. In both SOC 2 and ISO 27001 contexts, the quality of the conclusion depends heavily on how well the program was scoped and structured before fieldwork began. A program that is organized around relevant risk areas, with clearly defined objectives and tests, helps ensure the auditor examines what actually matters to the engagement rather than working from an ad hoc checklist. Without this structure, coverage gaps can go unnoticed and the resulting SOC 2 report or ISO 27001 audit findings may not withstand scrutiny.

It is important to understand what an audit program does and does not deliver. The program guides the work performed, but the outcome depends on what is actually tested and observed during the engagement. A well-constructed program does not by itself guarantee a clean SOC 2 report or a successful ISO 27001 certification decision, and it does not guarantee that an organization is free from control weaknesses or breaches outside the tested procedures and period. Its value lies in making the examination organized, risk-focused, and transparent, so stakeholders can understand what scope and criteria the conclusion rests on.

Because the specific procedures, sampling, and depth of testing are tailored to the engagement scope and applicable criteria, the content and rigor of an audit program vary by auditor and objective. Two engagements against the same framework can therefore look different in practice, which is why the program itself becomes a key artifact for understanding the boundaries of any resulting report or certificate.

Who it's relevant to

Auditors and Assessors

Auditors use the audit program as their working blueprint, setting objectives, identifying risk areas, and defining the tests and procedures that will support their conclusion. For CPA firms performing SOC 2 examinations or certification body assessors conducting ISO 27001 audits, the program keeps fieldwork organized, risk-focused, and defensible.

Compliance and GRC Managers

Compliance and GRC professionals rely on the audit program to understand what scope, timeline, and procedures an engagement will cover, allowing them to prepare evidence and coordinate internal resources. Reviewing the program also helps them see the boundaries of what a resulting report or certificate will and will not attest to.

Security Engineers and Control Owners

Those who operate and maintain controls use the audit program's defined procedures and tests to anticipate what will be examined and to ensure the relevant records and processes are ready. Because testing depth varies by scope, understanding the program helps control owners focus their preparation on the risk areas the auditor has prioritized.

Executives and Report Consumers

Leaders and downstream consumers of a SOC 2 report or ISO 27001 certificate benefit from understanding that the audit program frames what was tested. This context clarifies that a conclusion rests on the defined scope and observed results, not on a guarantee of freedom from all weaknesses or breaches.

Inside Audit Program

Scope Definition

A statement of the systems, services, locations, and time frame the audit addresses. For a SOC 2 examination this fixes the review period and the Trust Services Criteria in scope; for an ISO 27001 audit it defines the boundaries of the ISMS being assessed. The scope determines what the resulting SOC 2 report or ISO 27001 certificate covers and, by extension, what falls outside it.

Criteria or Requirements Reference

The authoritative basis against which the audit tests. In a SOC 2 context this is the Trust Services Criteria, with Security (the Common Criteria) always included and Availability, Processing Integrity, Confidentiality, and Privacy added depending on scope. In an ISO 27001 context this is the ISMS requirements in clauses 4 through 10, together with the Annex A reference controls selected through the Statement of Applicability.

Test Procedures and Methods

The specific procedures used to gather evidence, which typically include inquiry, observation, inspection of documentation, and re-performance. For a SOC 2 Type II engagement these procedures assess operating effectiveness over the review period, whereas a Type I engagement evaluates suitability of design at a point in time.

Evidence and Sampling Approach

The plan for collecting and, where relevant, sampling evidence across the review period. Sampling decisions and their sufficiency are matters of professional judgment and vary by auditor, engagement scope, and the nature of the control being tested.

Schedule and Roles

The timeline for fieldwork and the assignment of responsibilities. For SOC 2 this work is performed by a licensed CPA firm under the AICPA SSAE 18 standard; for ISO 27001 the audit is conducted by an accredited certification body against the management system standard.

Reporting or Findings Output

The intended deliverable of the program. A SOC 2 engagement results in an attestation report describing the controls and period covered, while an ISO 27001 audit supports issuance of a certificate covering the defined ISMS scope. These outcomes are distinct and should not be described interchangeably.

Common questions

Answers to the questions practitioners most commonly ask about Audit Program.

Is an audit program the same thing as the auditor's final SOC 2 report or ISO 27001 certificate?

No. An audit program is the internal plan and set of procedures that guides how an examination or assessment is conducted; it is a working document, not an outcome. A SOC 2 engagement results in an attestation report issued by a licensed CPA firm, while an ISO 27001 assessment can lead to a certification issued by an accredited certification body. The audit program supports arriving at those outcomes but is distinct from them.

Does having a documented audit program guarantee that controls are effective or that no breach will occur?

No. An audit program defines the scope, procedures, and evidence-gathering approach for an examination; it does not by itself make controls effective. A SOC 2 report attests only to the controls and period it covers, and an ISO 27001 certificate covers only the defined scope of the ISMS. Neither the program nor the resulting outcome guarantees freedom from breaches or issues outside the assessed scope and period.

How does an audit program differ between a SOC 2 Type I and a Type II engagement?

The program typically reflects the objective of each engagement type. For a SOC 2 Type I, procedures generally focus on evaluating the suitability of the design of controls at a point in time. For a Type II, the program additionally includes procedures to test operating effectiveness over a defined review period, whose length is set through scoping decisions rather than a fixed duration. The specific procedures depend on the auditor, scope, and applicable Trust Services Criteria.

How should an audit program address the Trust Services Criteria in a SOC 2 engagement?

The program is typically structured around the categories in scope. Security (the Common Criteria) is the only required category, so it is generally always addressed. Availability, Processing Integrity, Confidentiality, and Privacy are optional and included in the program only when selected based on scope. The program should map procedures to the criteria actually within the engagement's boundaries rather than assuming all categories apply.

How does an audit program relate to the ISO 27001 clauses and Annex A controls?

For an ISO 27001 assessment, the program typically covers the certifiable ISMS requirements in clauses 4 through 10, along with the Annex A reference controls that the organization has selected through its Statement of Applicability and risk assessment. Because Annex A was restructured in the 2022 revision, the program should reference the applicable version so that control coverage aligns with the edition in use. Not every Annex A control will appear if it was excluded through the Statement of Applicability.

Can a single audit program be used to satisfy both SOC 2 and ISO 27001 requirements?

Mapping between the two frameworks is possible but only partial, so a combined or coordinated program can reduce duplicated effort, but satisfying one framework does not automatically satisfy the other. In most engagements, the program still needs distinct procedures reflecting that SOC 2 is an attestation examination under the AICPA's SSAE 18 standard and ISO 27001 is a management system certification. The degree of overlap depends on scope, the applicable criteria, and the assessing party.

Common misconceptions

An audit program is a fixed, one-size-fits-all checklist that applies identically to every engagement.

An audit program is shaped by scoping decisions, the applicable criteria or requirements, and the auditor's professional judgment. In most engagements the test procedures, sampling approach, and review period are tailored rather than universal, so what is examined can differ substantially from one organization to another.

A single audit program can be reused to satisfy both SOC 2 and ISO 27001 without adjustment.

The two frameworks rest on different bases, the Trust Services Criteria versus the ISMS requirements in clauses 4 through 10 and the Annex A reference controls, and their outcomes differ (an attestation report versus a certification). Mapping between them is possible but partial, so satisfying one program does not automatically satisfy the other, and the procedures typically must be adapted.

Completing the audit program guarantees the organization is secure and free from breaches.

An audit program tests only the controls and, for a SOC 2 Type II, the period within its defined scope. A resulting SOC 2 report attests only to those controls over that period and does not guarantee freedom from breaches, and an ISO 27001 certificate covers only the defined scope of the ISMS.

Best practices

Define and document the scope precisely before building the program, specifying the systems, the review period, and the applicable Trust Services Criteria or ISMS boundaries so that everyone understands what will and will not be covered.

Align test procedures to the correct authoritative basis, the Trust Services Criteria for SOC 2 or the clause 4 through 10 requirements and selected Annex A controls for ISO 27001, and avoid conflating the two frameworks within a single set of procedures.

For SOC 2 engagements, tailor the program to the engagement type, testing suitability of design for a Type I and both design and operating effectiveness over the review period for a Type II.

When citing ISO 27001 Annex A control counts, specify the edition, since the numbers differ between the 2013 and 2022 revisions, and drive control selection through the Statement of Applicability informed by risk assessment rather than adopting all controls by default.

Coordinate the schedule and roles with the licensed CPA firm (for SOC 2) or accredited certification body (for ISO 27001) early, and confirm the evidence and sampling approach with them to reduce rework during fieldwork.

Where an organization pursues both frameworks, treat cross-framework mapping as partial rather than automatic, and plan supplementary procedures to close the gaps that overlap does not cover.