Audit evidence: designing controls that produce their own records.

Consider a common scenario in a first SOC 2 Type 2 examination. The auditor requests evidence that quarterly user access reviews were performed. The organization has a well-written access review procedure, and an administrator did review user lists and remove accounts. However, the work left no record, so nothing can be provided. The control was designed and operated, but its operation cannot be demonstrated, and for audit purposes the result is the same as if it had not operated.

This pattern appears across SOC 2, HIPAA, and NIST-based assessments. Addressing it requires treating evidence as an output of routine work rather than a task performed before fieldwork.

Design versus operating effectiveness

A SOC 2 Type 1 report addresses the design of controls at a point in time. A Type 2 report addresses both design and operating effectiveness over a specified period.¹² Type 1 is supported largely by documentation; Type 2 requires records showing that controls ran throughout the period. An organization can complete a Type 1 without difficulty and still encounter findings in its first Type 2 if it documented its controls without building the records to support them.

The same distinction applies to HIPAA. The Security Rule requires procedures to regularly review records of information system activity, such as audit logs and access reports, and requires covered entities and business associates to retain required documentation for six years from its creation or last effective date.³⁴ Termination procedures and workforce security requirements under the same rule raise the same question: whether the organization can show when access ended, not only that it ended.³

Completeness of the population

Auditors evaluate whether evidence is sufficient and appropriate, which includes whether it is relevant and reliable. A record created when a control operated is more reliable than one reconstructed later. One further consideration is easy to overlook: completeness. Before testing a sample, a service auditor evaluates whether information produced by the entity is sufficiently reliable, including whether it is complete and accurate.¹ A set of five onboarding tickets cannot be tested without a reliable list of everyone onboarded during the period. If the organization cannot produce that population, sampling cannot proceed.

Building records into routine work

The most effective approach arranges normal operations so that performing a control produces a dated record automatically:

• Route control activities through the ticketing system. Access reviews, terminations, vendor approvals, and exceptions recorded as tickets with dates, approvers, and attachments create both the population and the sample.
• Prefer system-generated output. An export from the identity provider carries its own provenance and is less likely to diverge from actual system state than a manually maintained spreadsheet.
• Record approvals with the action. Pull request approvals, change tickets with a reviewer field, and onboarding checklists with manager sign-off are more reliable than separate approval documents.
• Align retention with the audit period and regulation. Log retention shorter than the examination period, or ticketing systems that purge closed items, create gaps that cannot be corrected later.

Controls that most often lack records

Evidence gaps often appear in the following controls:

1. Access reviews performed without a record of what was reviewed and what changed.
2. Terminations where deprovisioning occurred promptly but the timestamps linking termination and deprovisioning were not retained.
3. Change management approvals given in chat that is not retained or cannot be tied to a specific change.
4. Vendor reviews conducted informally without a documented annual assessment.
5. Risk assessments completed once and not repeated at the required frequency.
6. Security training records maintained only for current employees, leaving the period population incomplete.

Each of these is a recording issue rather than a design issue, and each is inexpensive to correct before an observation period begins.

When an exception does occur, the response matters. In a SOC 2 Type 2 report, the service auditor describes the tests performed and their results, including any deviations identified. A documented explanation of the cause, the corrective action taken, and the date the control resumed normal operation gives report users the context they need to evaluate the exception.¹

Setting the start of the observation period

The timing of the observation period is one of the most consequential decisions in audit readiness. A practical sequence is to define the controls, link each to the record that will demonstrate it, run one internal cycle of each control, confirm that the records were captured and can be retrieved, and then begin the period. This preparation reduces fieldwork friction, remediation, and the risk of exceptions in the final report. For a first examination, a shorter initial period can allow the first report to reflect controls after this preparation is complete.

Practical takeaways

• Identify the record that will demonstrate each control before the observation period begins.
• Confirm that a complete population can be produced for every sampled control.
• Use ticketing and system-generated exports as the primary evidence sources.
• Align log and ticket retention with the audit period and regulatory requirements.
• Run a full internal cycle of each control before starting the period.