Control Monitoring Cadence Between SOC 2 Audit Cycles

Compliance with SOC 2 Type II fails after audits, not while they're happening. The gap between "we passed our audit" and "we're still compliant six months later" is really a scheduling issue pretending to be a tech problem, yet most organizations handle it the wrong way, getting another dashboard when they actually need a calendar.

What the AICPA Trust Services Criteria actually require organizations to monitor on an ongoing basis

The CC4 series spells out the specifics. CC4.1 requires organizations to choose, create, and carry out checks that confirm controls continue to meet their goals. Read that again: the obligation isn’t showing a control was once put in place. The goal is to show the control keeps working over time, a task unlike what many compliance teams usually handle.

CC4.2 points out what's often missed: problems must be reported promptly to those able to fix them, like senior management and the board. If a team fixes a broken control without reporting it to their superiors, they haven't met the criterion. Monitoring that doesn’t escalate issues is just observing.

CC1.3 also requires management to assess internal controls regularly, more often than just once a year or right before an audit. CC7.2 requires systems to be monitored and security events detected, so passive logging that no one checks is not allowed. NIST SP 800-137 offers a useful outside definition here: continuous monitoring means "maintaining ongoing awareness of information security, vulnerabilities and threats to support organizational risk management decisions." That phrase is worth keeping in your back pocket the next time an engineering lead asks why log review can't just happen "whenever."

The trick is, these criteria don't specify how often "ongoing" should happen. The AICPA doesn’t give you a schedule showing access reviews as monthly and vendor reviews as annual. This article intends to address that specific silent gap, tier by tier.

How the observation period length shapes which frequencies matter most

The AICPA standard doesn’t set a required minimum, yet three months usually serves as the baseline. Some controls produce evidence only at set intervals, so the auditor must wait for a full cycle to finish before they have something to review.

The rules for keeping evidence match how often the control happens. For weekly and monthly controls, evidence must be provided for each relevant period within the Type II window. If you skip a month, the auditor will notice the gap. Quarterly controls require proof for each quarter during the review period. Annual and semi-annual controls must appear once in the year before the window closes; thus, they don't need refreshing if the window is under 12 months.

How long you look back decides what you check. A 3-month window captures just one quarterly access review cycle, the minimum needed to prove the control operated. A 6-month window captures two quarterly cycles and one semi-annual BCP or DR test, making it a popular option for initial Type II reports. A 12-month window is the full obligation: every quarterly, semi-annual, and annual control needs documented proof, and nothing gets a pass.

Many organizations bypass Type I and jump right to Type II. That's a reasonable move for speed, but it means the first time these teams face a full-frequency obligation across every tier is also the moment when the post-audit motivation to keep up the paperwork tends to fade fastest. As renewal cycles generally last six to eight months, cadence needs to be year-round, not just when audit kickoff emails arrive. Many firms sync their audit timing with the client’s fiscal year to align with reporting needs. The lesson applies no matter which window you choose: cadence must be steady across the twelve, six, or three months you pick, not just the period that was easiest.

Daily and continuous controls: what automated monitoring must produce and how to verify it is working

This level includes alerts for suspicious logins, policy violations, configuration changes, encryption status, patch updates, uptime, and system integrity checks. SIEM or XDR platforms aggregate logs from cloud services, identity providers, and network devices. The tool itself doesn't count as the control. Auditors know the control is the documented review and escalation process tied to the tool, even if sales decks suggest otherwise.

Two metrics distinguish genuine continuous monitoring from mere alerting theatrics. Mean Time to Detect (MTTD) shows how quickly an event becomes an alert; a low MTTD (minutes to hours rather than days) tells auditors the monitoring is truly continuous. Auditors can verify it by comparing event timestamps. Mean Time to Remediate, or MTTR, shows the problem MTTD misses: a system that spots issues in ten minutes but takes three weeks to fix them still has ongoing control failure, just with faster alerts.

Escalations must follow their own schedule within the daily monitoring cycle. Critical findings open longer than four hours get escalated immediately, not at the next standup. Leadership gets weekly open risk counts. Every day, someone has to approve the compliance dashboard, no quick skim while grabbing more coffee.

Automation is useful here for more than just being convenient. Organizations doing manual evidence collection themselves can spend 550 to 600 hours a year on this work, while automated collection drops that to about 75 hours, based on data from thousands of security audits. That's roughly a 75% reduction, and it comes with timestamped, auditor-ready evidence instead of a Google Drive folder somebody assembled at 11pm the night before fieldwork. IBM's 2025 Cost of a Data Breach report showed 97% of organizations affected by shadow AI incidents lacked adequate access controls, and 16% of breaches involved attackers using AI tools. Continuous monitoring is designed to fix that specific detection gap.

Weekly controls: log review as a documented discipline, not a background process

Weekly activities include log review, exception triage (tickets, owners, deadlines), and reviewing daily automated alerts kicked out overnight. Auditors checking this tier don’t expect to see a SIEM license. Auditors want proof of a weekly routine tied to a real person who checked the logs and acted on them.

You need three infrastructure components to make it work: a centralized log platform that covers all in-scope systems, automated alerts set up for key categories, and logs stored securely. Without all three, the weekly review loses focus and becomes meaningless.

That rule packs more punch than you'd think. An exception found during weekly review has to generate a ticket with a named owner and a deadline attached. A verbal "yeah I looked at that, it's fine" in a Slack thread creates exactly the kind of gap an auditor can't sample, because there's nothing there to sample. A playbook helps teams follow a structured monthly rhythm alongside weekly reviews, with audits completed 40% faster and manual preparation effort reduced by 60%. The weekly habit is a brick that builds the monthly cycle.

Monthly controls: the access and vulnerability review tier that most teams under-document

Monthly tasks include checking access (especially where things change quickly), tracking vulnerabilities, verifying backup logs, contacting vendors, and managing alert reports. The documentation needs to clearly show who checked it, what was changed, and when that change started. The act of reviewing doesn't count as proof. The evidence is the paper trail the review leaves behind, not the review itself, though they're often confused.

Teams often cut corners on backup verification without realizing it. Just checking if the backup happened doesn't cut it. Backup records must list what was saved, the time, and proof a test recovery was done, otherwise it’s just a guess, not real protection. Incomplete backup logs are cited as findings more often than they need to be, since fixing them is easy.

One audit-readiness pattern to note: combining evidence collection and review at once causes evidence to become outdated. When data is gathered and evaluated in the same session, the reviewer ends up assessing their own work as they go. Monthly reviews should be scheduled separately from data collection to ensure the information is up-to-date and thorough.

This tier's vulnerability metrics should track remediation SLA compliance, not just if scans ran. If a vulnerability stays unpatched for 90 days because no one tracked the SLA, it's a finding, period, even if the scan schedule seems perfect. User access reviews stand out, they topped CBIZ’s 2024 SOC benchmark for qualified opinions. The problem isn’t missing the review. It’s done too quickly, with no proof that’d pass an auditor’s spot-check.

Quarterly controls: the tier where control failures most commonly surprise teams heading into audit

At a minimum, quarterly is when formal access reviews happen (though some organizations do them monthly), along with vulnerability scan reviews, remediation tracking, monitoring rule reviews, and internal audit rehearsals. Evidence standards match the monthly level: record who checked, what was altered, and when, each quarter. A missed quarter isn't a partial failure. It's a complete one, for that quarter, no partial credit.

People doing these checks by hand spot issues the tools overlook, glitches that don’t set off alarms but stand out when someone sees the real permissions. It doesn't replace automated scanning, it fills in where the scanner falls short.

Security, compliance, and engineering should all review monitoring rules together at least every quarter. Rule updates should incorporate insights from incident post-mortems and vulnerability trends, as detection logic that was initially accurate can drift over time due to environmental changes. Last year's rule settings won't work for this year's infrastructure.

Internal audit rehearsals also belong here: testing key controls mid-cycle with real evidence to honestly check for drift, not just for practice. A checklist makes it routine, not rushed, and leaves proof behind. The goal is to spot problems while there's still time to fix them before the audit window closes and a gap turns into a lasting issue. Vulnerability scans and BCP/DR tests often get neglected here, especially when teams stop scanning after audits or treat disaster recovery like just another task.

Semi-annual controls: BCP, DR, and the readiness checks that protect the second half of a 12-month window

Semi-annual controls often include BCP tests, DR drills, and readiness checks. For a DR drill, the evidence must be solid: drill notes, action items assigned to specific people, and confirmation that the recovery scenario was carried out. Talking about disaster recovery in a meeting doesn't count as testing it, even with detailed notes.

Test backups by restoring them regularly, and keep the proof on record. A backup existing isn't the same as a restore working; auditors check both separately, confusing many teams despite how obvious the difference sounds when explained.

A few firms run a simple readiness review before a major renewal or funding round, just a fast look to see if each cycle delivered what it promised. It's not a comprehensive review by internal auditors. It’s more like a quick oil check before hitting the road.

This level faces the same issue that undermines quarterly BCP/DR efforts: the focus maintained during audit preparation disappears as soon as the report is delivered. The fix isn't a reminder email. It’s a scheduled event with a clear owner and advance notice so the exercise isn’t pushed aside by this week’s emergencies. For organizations with shorter reporting cycles, the semi-annual tier may require more frequent attention. Each report requires its own full BCP/DR evidence, making it an every-period obligation.

Annual controls: the policy and vendor review tier that creates the longest lead time in the compliance calendar

The annual tier takes the longest and leaves no time for rushing: it needs official policy approvals and security checks for all vendors accessing systems or customer info. Evidence of a policy review includes documents with version control, the reviewer's name, and an approval date. Even if not violated, a policy not formally reviewed inside the window is a finding.

Vendor review covers more ground than most teams plan for at the start. Vendors accessing systems or customer data should have appropriate security documentation on record. Reviewing new vendors before onboarding helps prevent compliance gaps. A way to spot vendors who slip out of compliance later on is essential, because January’s all-clear doesn’t hold in October.

Under normal evidence retention rules, annual and semi-annual controls need to be verified just once before the window closes. The only good part of this whole schedule is that the tier with the longest lead time also needs proof the least often. The real work lies in the daily to quarterly controls, where the calendar, not the tools, determines if an organization faces its next audit prepared or caught off guard.