Configuration, periodic and ad hoc: how SOC 2 Type II evidence works with only Drive and spreadsheets

We have been following what practitioners are asking on Reddit, and one question keeps coming up: how do you collect SOC 2 Type II evidence with nothing more than Drive and spreadsheets? We listen to these discussions to share what is being talked about and to add to the conversation. This piece sets out the mechanics. The reader will learn the three evidence types, the record to keep for each, the population an auditor requests and how the sample is drawn from it.

SOC 2 is an attestation framework from the AICPA, the American Institute of CPAs. No UK law requires it. UK companies meet it when US customers ask for a report in procurement or contract terms, and an independent CPA firm issues that report.

What a population and a sample mean for Type II testing

A SOC 2 Type II report tests whether controls operated effectively across an observation period, often six or twelve months. A Type I report looks at design at a single date. The difference matters for evidence, because Type II needs proof from across the whole period, not from one day.

A population is the complete list of times a control operated or should have operated in the period. A sample is the smaller set of items the auditor picks from that list to test. Audit evidence is the record that shows one item was handled as the control requires. The auditor asks for the full population first and chooses the sample afterwards. The company does not choose which items the auditor sees.

For plain-language definitions of these terms, see Ideagen's explanation of how audit plans, sampling and evidence connect.

Audit firms set their own sample sizes. The pattern is that the more often a control runs, the larger the sample. An annual control may be tested with a single instance. A daily control may be tested with dozens. Confirm the approach with the auditor before the observation period starts.

The three SOC 2 evidence types and the record to keep for each

Configuration evidence: proving a setting stayed on

A configuration control is a system setting that enforces a rule, such as multi-factor authentication on the identity provider or encryption on a database. The record is a dated export or screenshot of the setting, with the system name visible, plus the change history showing it was not switched off during the period. The population is usually the list of in-scope systems and any changes to the setting. The auditor samples systems and checks each one.

Periodic evidence: proving a scheduled control ran every time

A periodic control runs on a schedule: a quarterly access review, an annual policy review or a backup restore test. The record is a completed, dated review that names the reviewer, the scope, the outcome and any actions raised. The population is each scheduled occurrence in the period. For a quarterly review that is four, and the auditor may test two of them. A missed quarter is an exception, so the schedule needs to be met.

Ad hoc evidence: proving every event was handled

An ad hoc control is triggered by an event: a new joiner, a leaver, a security incident, a code change or a new vendor. The record is one ticket or log row per event with timestamps for request, approval and completion. The population is every event in the period, and it is the type where gaps hurt most. A single event missing from the list means the population is incomplete.

Worked example: joiners and leavers across a 12-month period

Take a control that says leavers lose access to all in-scope systems within one working day of their last day. The company defines that timeframe, and the auditor tests against it.

The auditor asks for the population: every leaver in the 12 months. If 40 people left, the list must contain 40 names, exported from the HR system with the leaving date for each. The auditor selects a sample, for example 10 of the 40, and asks for three records per person: the HR leaving date, the access removal request and the identity provider log showing when the account was disabled. Each leaver is then checked against the one-day rule.

The same logic applies to joiners. The population is every new starter. The sample is checked for approval of access before it was granted, completed background checks where the company requires them and policy acknowledgement. The figures above are illustrative. The auditor sets the actual sample size.

The list must be system-generated, not typed by hand. The auditor will compare the leavers list against payroll or the directory to confirm that nobody is missing.

Where Drive and spreadsheet evidence breaks down and how to fix it

Drive and spreadsheets can hold SOC 2 evidence if the records are dated, complete and unchanged. These five patterns are places where they can fail the auditor's checks.

What goes wrong in a spreadsheet The record that fixes it What the auditor can then do
The joiners list is rebuilt from memory when the audit starts Export the list from the HR system or identity provider, dated, and keep the raw file Test completeness and draw a sample from the full population
Screenshots carry no date, system name or author Capture the setting with a visible timestamp and system name, or export the configuration file Confirm the setting was in place during the period
A quarterly access review happened but names no reviewer or outcome Keep a signed record with reviewer, date, scope and actions raised Count it as an instance of the control operating
The event log has gaps and some leavers are missing Log one row per event with request and completion timestamps, and reconcile to the HR list each month Find gaps before the auditor does
Evidence files are renamed or overwritten after the period Use one folder per control per period, named with dates and view-only once the period closes Rely on evidence that has not changed since it was created

How to evidence information security policies for SOC 2

The policy review and acceptance record is a good worked example because it combines two evidence types. The annual review is periodic. Each employee acknowledgement is ad hoc, because it is triggered by joining or by a policy change.

For the review, keep a policy register listing each policy, its owner, version, approval date and next review date. Keep every previous version. For each review, keep a record naming the reviewer, the date, the outcome and the changes made, plus evidence that management approved the result. For an annual review the population is one occurrence, and the auditor tests it.

For acceptance, keep one row per employee showing the policy version acknowledged and the date. The population is every employee in the period, including joiners. When a policy changes mid-period, the new version needs its own round of acknowledgements. The auditor samples employees and checks that each acknowledged the current version, and that joiners did so within the timeframe the company has set.

Which criteria the evidence maps to and why they are changing

The Trust Services Criteria are the AICPA's standards for SOC 2. Security is the category every report includes. Availability, confidentiality, processing integrity and privacy are optional additions. Leaver access controls map to the logical access criteria (CC6). Policy review and acknowledgement map to the criterion on deploying control activities through policies and procedures (CC5.3).

The criteria are being revised. On 26 October 2026 the AICPA published the AICPA's exposure drafts of the proposed 2027 Trust Services Criteria for public comment. These are proposals, not final requirements, and the criteria in force today remain the reference until any revision is finalised.

One habit makes any change easier to absorb. Keep a control register with one row per control and a column for the criteria it maps to. If the criteria change, the column is updated and the evidence stays as it is.

What to look for in information security policy management software in the UK

Policy evidence is where spreadsheets become hardest to maintain as staff numbers grow. Information security policy management software should provide:

  • Version history that keeps every earlier version with its approval date
  • Review dates with reminders, and a record of who completed each review
  • Staff acknowledgement records showing the version, the person and the date
  • Export on request, so the full population can go to the auditor without manual rebuilding

Keep the population complete and let the auditor choose the sample

SOC 2 Type II evidence comes down to a complete population and a dated record for every item in it. Configuration controls need proof that a setting stayed on, periodic controls need proof that each scheduled run happened and ad hoc controls need proof that every event was handled. Drive and spreadsheets can carry all three when lists are exported from source systems and files are kept unchanged.

Readers who want to continue the discussion can join practitioners in Ideagen's Reddit community.