ISAE 3402 evidence collection: what auditors actually test

Control description before evidence

Evidence collection only works if the control description is correct. Auditors test the control as it is documented. If the documentation says "every change to production code is reviewed by a second engineer before merge," the auditor expects to see a sample of merges with a documented second reviewer.

A common failure: the control description was written in the abstract before anyone confirmed it matches how the team actually works. The auditor finds exceptions not because the control failed, but because the description was wrong. Rewrite descriptions to match real practice before the period starts.

Walkthrough testing

For every control in scope, the auditor performs a walkthrough. The service organisation runs the control end-to-end while the auditor observes and documents what happens, who does what, and what evidence is produced.

Walkthroughs happen near the start of the engagement and at the end of the period to confirm nothing has changed. They are necessary for both Type I and Type II.

Detailed testing and sampling

For Type II, the auditor draws samples from the population of control occurrences across the period. Sampling approach varies by control frequency. A monthly control over a twelve-month period might be tested at all twelve occurrences. A daily control might be tested across a sample of 25 to 60 days depending on risk. Continuous controls (an automated access provisioning rule) are tested by inspecting the configuration and by sampling provisioning events.

For each sample, the auditor requests the evidence: the change-management ticket, the access-request approval, the backup-restore log, the monitoring alert. Evidence is captured in the auditor’s file with cross-references to the control objective and the sample selection.

Inquiry and corroboration

For controls that produce limited tangible evidence, the auditor uses inquiry (interviews with personnel) combined with corroboration (documents, observation, re-performance). Inquiry alone is the weakest form of evidence and the auditor will combine it with at least one other test.

Examples: training completion is often tested by inquiry combined with inspection of the LMS report. Risk acceptance decisions are tested by inquiry combined with inspection of the signed risk register entry.

Complementary user entity controls (CUECs)

A CUEC is a control the report assumes the customer (the user entity) operates on its side of the boundary. Common examples: customer personnel are responsible for managing their own user accounts and authorisations, customer personnel review reports generated by the service before relying on them.

CUECs are listed in the report and the customer’s auditor checks them on the customer side. They are not optional decoration; an omitted CUEC creates an unaddressed gap that the customer’s auditor will flag.

Common failure modes

• Control descriptions written in the abstract that do not match real practice. The fix: walk every control with the engineer who actually performs it, before the auditor does.
• Evidence not collected during the period and reconstructed after the fact. Reconstructed evidence is weak; auditors will note it and may qualify the opinion.
• Sample populations that change during the period without documented justification. The auditor cannot sample a moving target.
• CUECs that drift from the actual customer-facing documentation. Update the report’s CUEC list when the customer-facing terms change.
• Reliance on a sub-service organisation without addressing their controls. If you outsource a control to a sub-service organisation, either include their controls in the report (inclusive method) or carve them out and require the customer to obtain assurance directly (carve-out method).