SOC 2 Control Frequency Requirements by Control Type

SOC 2 deliberately leaves it to the organization to decide how often to run a control. The AICPA's Trust Services Criteria were built to apply across companies with wildly different systems, risk profiles, and customer commitments, so a fixed schedule written into the framework would either be too loose for a bank-grade processor or too strict for a five-person startup. The space the AICPA leaves open gets filled by something concrete: the organization's own written policies. Once a policy states that access reviews happen quarterly, or that vulnerability scans run weekly, that stated cadence becomes the standard an auditor measures against. A Type 2 auditor does not ask whether a control was good enough in the abstract. The auditor asks whether the control ran as often as the company said it would, across the full period under review. That turns every frequency commitment into an obligation the organization wrote for itself, and the rest of a SOC 2 program depends on getting that commitment right before the audit window even opens.

Matching control type to operating cadence

Before anyone drafts a policy, the nature of the control itself should settle roughly how often it needs to run. Three categories do most of the work: automated controls that operate continuously, event-driven controls that fire in response to a trigger, and periodic controls that run on a calendar. Automated controls, such as log collection, SIEM monitoring, cloud configuration snapshots, and access provisioning checks, need no human scheduler at all; they generate timestamped records throughout the audit period on their own. Event-driven controls respond to something happening, a major system change, a new vendor, a reorganization, and the obligation is to document a reassessment each time that trigger occurs, not on a fixed date. Periodic controls are the most familiar to anyone who has sat through a compliance meeting: weekly, monthly, quarterly, or annual tasks assigned to a human owner.

The cadence chosen for a periodic control has to match what the organization can actually sustain. A monthly access review that slips to once every six weeks looks worse to an auditor than a quarterly review performed on time every quarter, because the missed instances in the first case become a documented population of failures, while the second case simply meets its own bar. This is the first place where ambition and operating reality need to be reconciled, and the table below maps the three categories to the kind of evidence each one produces.

| Control type | Example | Evidence form | |---|---|---| | Automated (continuous) | SIEM monitoring, log collection, access provisioning checks | Ongoing, timestamped export covering the full audit window | | Event-driven | Risk reassessment after a system or vendor change | Change record paired with a dated reassessment document | | Periodic | Access reviews, vulnerability scans, policy re-approval | Scheduled artifact produced on the calendar stated in policy |

Auditors increasingly expect the first column to produce programmatic exports rather than a single screenshot pulled the week before fieldwork starts. A control that only shows evidence from the final two weeks of a twelve-month period has not demonstrated that it ran continuously, regardless of how clean that evidence looks.

Continuous and daily controls: what CC7 and CC4 require as evidence

Continuous means the control produces dated, exportable records proving it operated throughout the entire audit window, not just at the moment the auditor happens to ask. CC4.1 and CC4.2, grouped under Monitoring Activities, call for control owners to review the controls assigned to them and document whether each one operated as written, with any deficiencies reported to management along with assigned corrective actions. Neither criterion specifies an exact review frequency; common practice sets that review at least annually, with many organizations choosing quarterly, but the monitoring feeding those periodic reviews needs to run without interruption. CC7, covering System Operations, carries the same expectation for the underlying technical controls: log collection and configuration monitoring need to produce a steady stream of records, not a single export.

A year-end pull instead of continuous retention leaves gaps that an auditor requesting evidence from month four or month seven of a twelve-month window will find nothing to examine. That gap turns a control that may have worked fine in practice into one that cannot be verified, which is functionally the same as a failure in a Type 2 report. Vulnerability management is the first control that layers a genuine calendar on top of this continuous baseline, and it is where frequency debates start in earnest.

Weekly and monthly controls: vulnerability management cadence and the "ongoing monitoring" standard

Vulnerability scanning is where SOC 2's silence on frequency meets the clearest practitioner consensus. Weekly scans are the accepted standard for internet-facing assets, while quarterly scanning is considered the floor for lower-risk internal systems that sit behind other layers of control. Annual or ad-hoc scanning falls short of the "ongoing monitoring" expectation that auditors apply under CC7, because a single scan per year cannot demonstrate that new vulnerabilities introduced throughout the year were caught in any reasonable window.

Scanning frequency is only half the obligation. Patch SLA compliance is the paired control, and missed patch SLAs are among the most commonly cited findings in SOC 2 audits. Running a weekly scan that identifies a critical vulnerability means nothing to an auditor if the remediation record does not show the fix landed within the window the organization's own policy promises, whether that's 15 days for critical findings or 30 for high-severity ones. Event-driven scans, triggered by a major infrastructure change, supplement this calendar. A new production deployment might trigger an out-of-cycle scan, but the next scheduled weekly or quarterly scan still runs on its normal clock regardless of what the triggered scan found. Frequency here is a function of risk and how fast the environment changes, and a policy that doesn't reflect that creates a gap an auditor will eventually find.

Quarterly controls: access reviews and monitoring-activity documentation under CC6 and CC4

Quarterly access reviews generate more first-time audit findings than almost any other control. The failure pattern is rarely a missing control; it's a missing artifact. CC4.1 requires the entity to select, develop, and perform ongoing or separate evaluations to confirm that internal controls are present and functioning, but the criterion itself does not prescribe a reviewer role, a documentation format, or a quarterly cadence. CC4.2 adds that deficiencies must be reported to management and the governing body with corrective actions assigned, communicated in a timely manner. Quarterly has become the practitioner norm for collecting this evidence because waiting until year-end to surface control failures defeats the purpose of ongoing monitoring.

The evidence an auditor wants is specific: a dated list of all active accounts, a sign-off from the reviewer, and a record of any accounts flagged for removal along with the date access was actually revoked. Organizations that perform the review verbally, or that review access without producing that dated record, have effectively not performed the control at all from an audit standpoint. The most common consequence of a missed or incomplete quarterly review is a former employee who still has active access months after departure. That finding gets filed under CC6, because the access control itself existed and was designed correctly; it simply was not operated on the cadence the organization promised.

An organization that writes "monthly access reviews" into its Access Control Policy but only performs them quarterly has created a policy deviation independent of whether any unauthorized access actually occurred, because auditors test against the written policy, not against what the team considers reasonable in practice. Penetration testing sits in a related but separate tier: annual testing, covering both external and internal systems, is the practitioner norm, supplemented by targeted tests after major changes, which places it across both the periodic and event-driven categories described earlier.

Annual controls: governance, policy review, risk assessment, and vendor management cadence

Annual controls form the foundation of the program, distinct from its day-to-day operation. Risk assessments, policy approvals, and vendor reassessments all run on a yearly clock, and a lapse in any one of them produces findings that reach beyond a single operational gap into the credibility of the governance structure itself. Policy review is the clearest case: policies must be reviewed and re-approved on whatever schedule the policy states, typically annual, and a lapsed review generates a CC2 exception. The obligation here is self-imposed in the most literal sense. A policy document that states "reviewed annually" has created a yearly deadline for a dated re-approval, and missing that deadline is itself the finding, regardless of whether the policy's content was still accurate.

Security awareness training under CC2.2 follows a similar logic but with a timing nuance that trips up first-time Type 2 candidates. Auditors look for evidence that training occurred throughout the observation period, not only once near the start of the year. The standard cadence pairs an annual refresher with onboarding training for new hires, backed by completion records, signed acknowledgments, and quiz results as the evidence artifacts an auditor will request. Vendor management operates on a comparable annual rhythm, reassessing third-party risk on a fixed schedule while also responding to material changes in a vendor relationship as they arise. These annual controls don't monitor day-to-day operations themselves; they anchor the design of the program that the operational controls, reviewed in the sections above, are meant to carry out. A failure at this level calls the whole structure into question. That is why auditors treat sample sizing for these controls with particular care.

How operating cadence shapes sample populations and testing exposure

The frequency an organization commits to in policy has a direct mathematical consequence in the audit room. A control documented as running weekly across a six-month observation window produces a fixed population, in this case, roughly twenty-six instances, and the auditor draws a sample from that full population rather than from a smaller set the organization gets to choose. A control documented as running quarterly over the same window produces only two instances, and an auditor may need to test both. The stated frequency is not a formality sitting next to the control description; it is the denominator the entire sampling exercise is built on.

The AICPA does not mandate specific sample sizes. CPA firms develop their own sampling methodology, drawing on the AICPA's SOC 1 and 2 Audit Guides, the AICPA's Audit Sampling Guide, and AU-C Section 530, and the factors that methodology weighs include how often the control runs and the expected rate of deviation from how it's supposed to operate. A control tied to a past finding or operating in a higher-risk area gets tested more heavily than a high-frequency, low-risk control with a clean history, because the auditor's judgment about deviation risk shapes the sample as much as the raw count of instances does.

The consequence for any organization preparing for a Type 2 report is straightforward: controls need to be operated and evidenced at the cadence the policy states across the entire audit window, not concentrated in the weeks before the auditor shows up. Treating SOC 2 as an annual sprint, producing a clean batch of evidence right before fieldwork begins, does not protect against this. If a control ran inconsistently for nine months and perfectly for the final three, the auditor's sample still reaches back across the full period, and the inconsistent months appear as exceptions regardless of how polished the year-end evidence looks.

Setting defensible frequencies

A consistent, realistic cadence produces a cleaner Type 2 report than an ambitious cadence the organization cannot sustain, because a policy deviation is its own finding, separate from whether the underlying control actually protected anything. The calibration process starts with control type. Automated controls need retention and export policies that guarantee continuous evidence. Event-driven controls need a clear definition of what counts as a trigger, so that a reassessment or a scan can be tied back to the event that caused it. Periodic controls need a calendar commitment that the operations team can actually keep quarter after quarter, not one that looks good in a policy document but slips in practice.

Risk gets layered on top of that baseline. Higher-risk systems and environments with faster rates of change justify higher frequency, and review cycles or access revocation deadlines should reflect the specific risks and commitments of the organization rather than copying a number from another company's policy. None of these frequencies are universal SOC 2 rules; they are judgment calls the organization makes and then has to live up to for the length of the audit period.

The frequency table embedded in an organization's own policies is the first thing an auditor reads, and it functions as the source of truth for everything that follows. A control without an explicit stated cadence forces the auditor to infer one, and that inference is never as favorable as a clear, consistently met commitment written down in advance.