SOC 2 Type 2 Controls: Operating Effectiveness (2026)

A SOC 2 Type 2 control is tested for operating effectiveness. The auditor takes the full list of times the control should have run during the audit period, samples from it, and checks each sampled item for dated evidence. The question is whether the control ran every time it was due, not whether it exists. A missing or undated instance is a deviation.

Our controls library holds 82 example controls, and the SOC 2 controls list shows what must exist across the period for each one. This page explains the mechanism behind those lines: how a population forms, which tests auditors use, and what happens when an instance is missing. No standard requires compliance software: a manual process that keeps a complete, dated population and a record for each instance meets the same test.

What does “operating effectively over a period” mean for a control?

It means the control ran every time it was due between the first and last day of the examination period, and left evidence you can date. A Type 1 report checks design on one date. A Type 2 report tests samples from across the period, so one good quarter does not cover a missed one.

Common planning windows run from 3 to 12 months (observation period guide). An approval dated before the period began is not an instance inside it.

Take a quarterly access review. Under Type 1, one completed review shows the process exists. Under Type 2 with a six-month period, the auditor expects the review for every quarter due in that window, each with a dated record. The Type 1 vs Type 2 guide covers choosing between the reports.

When the auditor looks matters too. Linford & Co, a CPA firm, says fieldwork may be split into touchpoints during the year or done close to the period’s end, and that the report usually follows the period end by a month or two. A control that passed an early touchpoint still has to operate through the last day, so ask your firm how it schedules coverage of the rest of the period.

How does control frequency set the population an auditor tests?

The population is every instance of the control that fell inside the period, and its size follows from the control’s cadence. A quarterly control gives two instances in six months. A per-event control gives as many as the system recorded. A continuous control gives no countable instances, so it is tested another way.

How many instances an auditor tests at each cadence, and how a deviation extends the sample, is covered in how auditors decide SOC 2 sample size. This page covers what each instance has to show.

Two points about populations catch teams out. First, the population has to come from the system of record and has to be complete. Linford says an auditor can obtain and review the queries behind an export to confirm nothing was filtered out. A hand-built list of “the terminations we remember” fails that check. Second, annual controls are fragile in short periods. If BC-03’s last restore test was dated before the period began and the next falls after it ends, no instance sits inside the period. Schedule the test inside the window.

Which tests do auditors use, and why is inquiry never enough?

Auditors use four kinds of test: inquiry (asking), observation (watching), inspection (examining records) and reperformance (doing the control again and comparing results). Inquiry alone is never enough: the AICPA’s SOC 2 guide says it “does not provide sufficient appropriate evidence of the operating effectiveness of controls.”

The quoted sentence is paragraph 3.129 of the AICPA SOC 2 guide (October 2022 edition), which adds that inquiry combined with inspection or reperformance ordinarily gives more convincing evidence than inquiry combined with observation. Linford & Co describes the same order from its own SOC work. Some firms add data analysis tools that test the whole population instead of a sample.

Linford lists them in order of complexity and calls reperformance the strongest. In practice a test of one control combines several, and observation, which covers only the moment the auditor watches, supports inspection across the period rather than replacing it.

How does the type of control change the test?

Manual recurring controls are tested by inspecting each sampled cycle, event-driven controls by sampling from a complete event list, and automated controls usually by testing the control once and then checking that nothing changed it during the period. The more a control depends on a person, the more instances there are to miss.

Manual recurring controls, such as AC-06, have small populations. The auditor inspects each sampled review for the reviewer, the accounts covered, the decisions and proof that removals happened. With two or four cycles, a single miss is a large share of the population, which is why small populations leave no room for error. The sample size guide works through how many quarterly reviews get tested.

Event-driven controls, such as AC-03 and CM-01, are tested by tracing sampled events from trigger to approval. The check is usually about order and independence: was approval recorded before the account was created, and did someone other than the author approve the merge? The common failure in our library is an approval written after the fact, in a ticket opened once the account already existed.

Automated controls, such as the branch protection setting behind CM-01 or the logging configuration behind LG-01, work differently. Linford says a “test of one” is completed for an automated control using reperformance, whereas a sample is drawn for an inspection control. A system applies a rule the same way each time, but only while nobody changes the rule. The PCAOB’s standard for audits of internal control over financial reporting, AS 2201, states the same logic: an auditor may conclude an automated control continues to operate if the general controls over program changes and access are effective and the control has not changed since it was last tested. AS 2201 is not a SOC 2 standard, but the reasoning carries over.

For you, that means evidence of the setting is not enough. Keep the record that it stayed in force: the configuration change history, the list of people who can bypass branch protection, and a log of each bypass. An unreviewed bypass weakens the reliance an auditor can place on a one-time test.

What evidence has to be kept, and how must it be dated?

Each instance needs an artifact generated by a system or signed by a named person, a date inside the period, and a link to the control it supports. For reviews, the artifact must also show the reviewer’s decision and proof that follow-up happened, not just that a list existed.

For AC-06, that means the dated export used for the review, the sign-off with reviewer and decisions, and the tickets showing removals were carried out. Missing any of the three leaves a gap the sample can find.

Three timing problems recur:

• Log retention shorter than the period plus fieldwork. If the report lands a month or two after the period ends, retention must still cover the period’s first day when the auditor tests. LG-01 names this as a common gap.
• Records recreated after the fact. If a review was done but nothing was saved, tell the auditor what happened. A record rebuilt later is weaker evidence than one made at the time.
• Screenshots standing in for populations. A screenshot shows items, not that the list was complete.

The evidence request list covers what to pull from each source system.

How is a logging and monitoring control tested over six months?

An auditor tests LG-01 by inspecting configuration and pulling events from both ends of the period, and tests LG-02 by sampling the alerts raised in the period for a triage record. This example uses a period of 1 January to 30 June and illustrative figures, not a real engagement. Both controls support CC7.2, which in the AICPA’s Trust Services Criteria asks the entity to monitor system components for anomalies and analyze them “to determine whether they represent security events.” LG-02 also supports CC7.3, which asks it to evaluate security events to determine whether they are security incidents.

LG-01 (central, protected logs that cover every in-scope system) has no countable instances. The auditor inspects that audit logging is on in every cloud account and region, compares the list of log sources with the system inventory, and checks retention. Then the auditor pulls events dated in early January and late June to confirm the whole period is there. The library’s gap for this control is a cloud account added mid-period that was never connected, or retention that deletes the first months before fieldwork.

LG-02 (alerts routed to an owner with a recorded triage decision) is tested by sampling:

1. Population: the monitoring tool’s export of every alert raised from 1 January to 30 June, say 412. The auditor reviews the query behind the export.
2. Sample: the auditor draws a sample from that list; the sample size guide covers how many.
3. Test: for each sampled alert, inspect who acknowledged it, when, and what the decision was against the written severity criteria.
4. Deviation: one alert has an emoji reaction in a chat channel and no recorded decision. The auditor extends the sample to see whether the miss was isolated and finds no further misses.
5. Write-up: the result goes into the report’s testing section.

An illustrative entry, in the format reports commonly use:

One exception like this does not automatically modify the opinion. The auditor weighs severity and spread, as explained in the exceptions guide. Which log sources to connect is covered in SOC 2 security controls.

What happens when an instance is missing?

A sampled instance with no dated evidence is a deviation. The auditor usually extends the sample to see whether the miss was isolated, the confirmed deviations go into the report as an exception, and management may add a response in an unaudited section. Whether the opinion changes depends on severity and pervasiveness, not on the count alone.

Linford describes the sequence: when an error appears, the auditor expands the sample or performs additional tests, then considers whether the errors are isolated or systemic. With small populations there is little room, because a skipped quarterly review is half the population.

Management’s response sits outside the auditor’s opinion, often in the optional section the company writes itself (SOC 2 audit report guide). Treat it as a commitment to fix the control going forward, not proof that the period was clean.

Timing is the other lever. Sensiba, a CPA firm, advises testing your own controls partway through the first period, because finding a deficient control at the end can force an extension of the review period while you fix it. Interim testing is optional, but it leaves the rest of the period for a repaired control to operate.

What does compliance software change for Type 2 evidence?

Software changes how evidence is collected, not what the auditor must conclude. A tool can pull dated records on a schedule, but the auditor still has to establish that the population is complete and accurate and that the evidence is sufficient. The AICPA says these tools are meant to improve efficiency.

The AICPA’s FAQ on the effect of software tools on SOC 2 examinations, dated 31 March 2026, describes tools as designed to improve the efficiency with which service organizations can prepare for and undergo SOC 2 examinations. Linford’s summary of the 2021 edition says the same standards for evidence collection, independence and objectivity apply with or without a tool, and a CPA firm cannot simply download a report from a tool. The firm has to validate the data, sometimes at the source system for higher-risk controls.

Three consequences for a Type 2 period:

• Nothing requires software. A manual process meets the same evidence standard: a complete, dated population and a record for each sampled instance.
• A tool sees only the systems connected to it. The LG-01 gap, an account nobody connected, applies to a platform’s integrations as much as to a log store.
• A person still makes the review decision in AC-06. A tool can prompt and record it, but cannot supply the judgment.

Our SOC 2 automation guide compares what platforms automate and what still needs a person.

What should you settle with the auditor before the period starts?

Agree the mechanics before the first day. Ask each firm you shortlist from the auditor directory:

• Which system is the source of truth for each population, and what export will you accept?
• How are controls handled when a cycle lands on the first or last day of the period?
• When are the touchpoints, and which controls are tested at each?
• What does the firm test once, and what change evidence must you keep to support that?
• How does it extend a sample when a deviation appears?

The readiness assessment shows which controls have no owner or recurring evidence yet. Fix those before the period opens, since a gap found inside the window is already in the report.