SOC 2 Control Testing Schedule: Annual Testing Planning

Priya Nandakumar found the gap on a Tuesday in October, nine months into a twelve-month Type II report window she had personally promised the board would be "boring." Priya runs compliance at Solstice Ledger, a mid-market payments platform that routes roughly $80 million a month in merchant settlements for about 600 e-commerce clients. Solstice's biggest prospect — a $2.4 million annual contract with a national retail chain — was contingent on a clean SOC 2 report covering January through December. When Priya pulled the evidence folder for CC6.1 (logical access provisioning) to prep for the auditor's Q4 interim testing, she found exactly one screenshot, dated January 14. Nobody had tested — or evidenced — that control again in nine months. The auditor's sample would almost certainly pull from March, June, and September. Two of those months had nothing.

That gap wasn't a control failure. Solstice's access provisioning process was, in fact, working fine. The failure was scheduling: nobody owned the calendar that said "test this control on this date, keep this evidence, here." Priya spent the next three weeks reconstructing evidence retroactively — a stressful, expensive, entirely avoidable scramble that a one-page testing calendar would have prevented. This article is the calendar Priya built afterward, and the one we now hand every client before their first audit period even starts.

Who this is for, and what you'll walk away with

This is for the compliance lead, engineering manager, or fractional CISO who has already mapped controls to criteria and now needs to keep them alive for the twelve (or six) months an auditor is going to sample from. You'll walk away with a cadence taxonomy for every control type, a sample annual test calendar you can adapt directly, a RACI model for who tests what, sampling guidance for testing your own controls before the auditor does, and a plan for tying manual testing to automated continuous monitoring so evidence never goes stale. If you've already read our guide to the SOC 2 control matrix, this is the next document you build: the matrix tells you what controls exist; the schedule tells you when you prove they work.

Why a testing schedule is a different document than a control matrix

Most teams building toward SOC 2 do the mapping exercise well: every Trust Services Criteria point of focus gets a control, every control gets an owner, every control gets a policy citation. Then they stop, because the control matrix looks complete on a spreadsheet. But a control matrix is a static snapshot — it says a control exists. A testing schedule is a living calendar that says a control operated, repeatedly, across the entire window an auditor is going to examine. For a Type II report, the auditor isn't asking "do you have an access review process?" They're asking "show me evidence this ran in March, and July, and November, consistently, the way your policy says it should."

That distinction is where most first-time (and plenty of second-time) SOC 2 programs get hurt. The Common Criteria alone span roughly thirty distinct control activities across CC1 through CC9 once you break policy commitments into discrete, testable actions. Add Availability, Confidentiality, or Processing Integrity criteria, and a mid-size service organization can easily be running 45-70 distinct controls simultaneously, each with its own natural cadence. Nobody holds that in their head. You need a document — a real, dated, owned calendar — or controls quietly lapse the way Solstice's did.

Continuous, daily, monthly, quarterly, annual: the five-cadence taxonomy

Every control you build has a natural frequency baked into what it's protecting. Forcing every control onto the same testing rhythm — either testing everything monthly (expensive, ignored) or testing everything annually (leaves nine-month gaps like Priya's) — is the single most common design mistake in a testing calendar. Start instead by sorting controls into five buckets.

Table 1: The Five Control-Testing Cadences

The taxonomy isn't arbitrary — it should trace back to how the control was worded when you built your SOC 2 control matrix. If your access review policy says "quarterly," your testing schedule tests it quarterly — not monthly because that feels safer, and not "as needed" because that's not a cadence an auditor can sample against. Consistency between what your policy commits to and what your calendar actually executes is, by itself, one of the top three things auditors flag in Type II report testing.

The observation period, and the coverage math nobody explains up front

A Type II audit period is commonly three, six, or twelve months. Whatever window you and your auditor agree to, every control in scope needs evidence spanning that entire window — not just a healthy sample near the start. Here's the coverage math that catches first-timers: for a control tested monthly, a twelve-month period requires 12 discrete evidence instances. For a control tested quarterly, four. For a control that's continuous (like MFA enforcement logs), the auditor will typically want a system-generated report covering the full period, not spot exports.

Table 2: Minimum Evidence Instances by Cadence and Observation Period Length

The trap in that last row: an annual control — say, your formal risk assessment refresh — has to have actually happened inside the observation window, not six weeks before it started. Auditors will not accept a risk assessment dated the prior November as coverage for a Type II period beginning in January unless you can also show ongoing risk monitoring inside the window itself. Build annual-cadence controls into the very first month of your period, not the last, so there's zero ambiguity about whether they land inside the window.

Mapping controls to cadence across the Common Criteria

Below is a representative mapping across CC1-CC9 plus the optional criteria — adapt the specific controls to your own SOC 2 control matrix, but the cadence logic transfers almost directly.

Table 3: Control Cadence by Common Criteria Category

Building the calendar: a five-step methodology

Once cadence is assigned per control, the actual calendar-building process is mechanical, but skipping any of these five steps is exactly how Priya's gap happened.

1. Start from your control matrix, not from a blank sheet. Every row in your SOC 2 control matrix becomes a row in the testing schedule. If a control isn't in the matrix, it shouldn't be tested; if it's in the matrix, it must have a cadence.

2. Assign a named owner, not a team. "IT team" is not an owner an auditor — or a corrective action plan — can hold accountable. Name a person.

3. Set a specific evidence date, not a month. "Sometime in March" becomes "the 15th of every month" or "the first Monday after quarter close." Specificity prevents the drift that ate Priya's Q1 access review.

4. Define what "done" looks like before the first test runs. A screenshot, an exported CSV, a signed attestation, a ticket closed with an audit trail — decide the artifact type in advance so control owners aren't improvising evidence formats nine months in.

5. Route every test through a reviewer. Self-testing without a second set of eyes reintroduces the exact segregation of duties problem SOC 2 is designed to catch. A manager, compliance lead, or internal audit function should review and countersign.

"The calendar isn't the control. It's the thing that makes sure the control keeps existing after the kickoff meeting excitement wears off." — Marcus Feldt, Audit Partner, Kessler & Voss CPAs

Sample annual test calendar

Below is a condensed, representative annual testing calendar for a mid-size SaaS service organization covering Security plus Availability criteria, across a twelve-month observation period beginning January 1. Adapt cadence and owners to your own environment — the structure is what matters.

Table 4: Sample Annual SOC 2 Control Testing Calendar

This calendar deliberately front-loads the annual-cadence controls (risk assessment, policy re-approval) into January so they unambiguously fall inside the window, and back-loads the year-end self-assessment into December so gaps surface with time to remediate before the auditor's final fieldwork — not after.

Who tests: building a RACI for control testing

A recurring failure mode is treating "who tests the control" as self-evident. It rarely is, especially as headcount grows and the person who built a control isn't the person still running it a year later.

Table 5: Control Testing RACI

The critical design rule: the person who is Responsible for running a control's day-to-day operation should rarely also be the sole Accountable reviewer of whether it was tested correctly. That's not bureaucracy for its own sake — it's the same segregation of duties logic that shows up throughout CC5 and CC8. A control owner tests their own work; someone one level removed reviews the evidence before it's filed.

Sampling your own controls before the auditor does

Here's a nuance most internal testing programs miss: you don't need to test 100% of every instance of every control to have confidence it's working — the same audit sampling logic your external auditor will use applies internally too. If your access review control runs against 40 employees every month, you don't need to manually re-verify all 40 to catch drift; a defensible internal sample, applied consistently, does the job at a fraction of the cost.

Table 6: Internal Sample Sizing Guidance by Control Frequency

For low-frequency, high-consequence controls — an annual risk assessment, a full DR failover — a test of one is standard and expected; there's only one instance to test. For high-frequency, high-volume controls, calculate a defensible population (audit) and sample from it the way your external auditor will, so your internal deviation rate estimate is a realistic preview of what they'll find. If your internal sample turns up a 15% deviation rate on access reviews, assume the auditor's sample — likely larger and less forgiving — will surface it too, and fix it before interim testing, not after.

"We started running our own control testing with the exact same sampling math our auditor uses. It stopped being a surprise every fieldwork cycle — we already knew where the weak spots were." — Rafael Ibsen, Internal Audit Lead, Northfield Analytics

Evidence timing: making sure the Type II window is fully covered

Evidence timing is where testing schedules quietly fail even when the tests themselves happened. A control that ran correctly but whose evidence was captured outside the sampled evidence window, overwritten by a later export, or filed without a clear timestamp is functionally the same as a control that didn't run, from the auditor's perspective. Audit evidence has to be dated, attributable, and retained for the full period plus the time it takes to complete fieldwork.

Table 7: Evidence Requirements by Cadence

Build evidence capture into the test itself — never as an afterthought. If a control owner runs an access review in a live admin console, the test step should explicitly include "export and timestamp the results," not just "review the list." That single habit is the difference between Solstice's nine-month gap and a clean audit trail.

Continuous monitoring: the backbone that keeps the calendar honest

A testing calendar built entirely on manual, human-driven reviews will always be fragile — people go on leave, change roles, or simply forget. That's why the calendar should lean as heavily as possible on continuous monitoring tooling for the controls that support it, reserving manual testing for controls that genuinely require human judgment. Our companion piece on SOC 2 continuous monitoring goes deep on the tooling side; here, the relevant point is scheduling: continuous monitoring doesn't replace your testing calendar, it feeds it. An automated control (say, MFA enforcement) still needs a monthly or quarterly checkpoint where a human confirms the monitoring tool itself is still configured correctly and alerting as expected — monitoring the monitor.

Table 8: Manual Testing vs. Continuous Monitoring by Control Type

The controls in the "manual" rows are exactly the ones your testing calendar should protect most jealously — they don't self-report, and if nobody schedules them, nobody notices they didn't happen until an auditor asks.

Tying the calendar to your internal audit program

A testing calendar without a review layer is just a to-do list — it becomes a control when someone independent checks that the to-dos actually happened, correctly, on schedule. That's the job of your internal audit program: a structured, recurring self-assessment that sits between "control owner says it's fine" and "external auditor tests it in six months." At minimum, internal audit should reconcile the testing calendar against actual evidence quarterly — not just check that a file exists, but verify dates, sample sizes, and reviewer sign-offs are all present and internally consistent.

Table 9: Quarterly Internal Audit Rhythm Against the Testing Calendar

This rhythm is what would have caught Priya's gap in April, not October. A quarterly reconciliation against the calendar — a simple "did month 2, 3, and 4 all get their evidence filed?" check — takes an internal auditor perhaps two hours a quarter for a control set the size of Solstice's. It is, by a wide margin, the cheapest insurance in the entire SOC 2 program.

"Internal audit isn't there to catch people doing something wrong. It's there to catch the calendar quietly not happening, which is a much more common failure mode than anyone wants to admit." — Toni Okafor, CISO, Vantage Point Health

Monthly cadence in practice: access reviews and vulnerability remediation

Two control families dominate the monthly-cadence bucket for most service organizations: privileged access control reviews and vulnerability remediation tracking. Both are high-volume, high-consequence, and both degrade fast without a fixed monthly rhythm.

For access reviews, the monthly test isn't a full recertification (that's usually quarterly) — it's a targeted check on privileged accounts: admins, database superusers, production deploy keys, and anyone with standing access to customer data. The control owner pulls the current privileged roster, compares it against an HR roster of active employees in privileged roles, and flags mismatches. Evidence is the comparison itself, dated and signed.

For vulnerability scanning, the monthly test checks remediation SLA adherence, not scan execution (scans typically run continuously or weekly via tooling). The monthly checkpoint answers: are critical findings closed within the committed SLA (commonly 15-30 days for criticals, 30-90 for highs)? Evidence is a report from the vulnerability management platform showing open findings against their age, with anything past SLA flagged and assigned a corrective action plan.

Table 10: Monthly Control Testing Checklist Template

Quarterly cadence in practice: vendor risk and access recertification

Quarterly-cadence controls typically involve more judgment and more people than monthly ones, which is exactly why quarterly is the right frequency — testing them monthly would burn reviewer goodwill for marginal benefit, and testing them annually leaves too much drift. Standard access recertification (as opposed to the monthly privileged-account spot-check) asks every manager to review their direct reports' access to in-scope systems and confirm it's still appropriate. Vendor risk management reassessment for critical vendors follows a similar logic: confirm the vendor's SOC 2 report or equivalent attestation is current, check for any reported incidents, and reconfirm the relationship still needs the access it has.

Table 11: Quarterly Control Testing Checklist Template

Completion rate matters as much as completion. An auditor sampling a quarterly access recertification will notice — and flag — if only 70% of managers actually attested. Track completion percentage as its own metric inside the calendar, with an escalation path (typically to the executive sponsor) for chronic non-responders.

Annual cadence in practice: risk assessment, DR testing, and pen testing

Annual-cadence controls are the most expensive per-instance and the easiest to under-resource, because "once a year" makes them feel optional in any given month. They aren't. A formal risk assessment refresh, a full disaster recovery failover test, and an annual penetration testing engagement are each, individually, load-bearing evidence an auditor will specifically ask for by name — there's no continuous-monitoring substitute for any of them.

Table 12: Annual-Cadence Controls and Lead Time Requirements

The lead-time column is the one most first-time programs ignore, and it's the one that causes the most schedule slippage. A penetration test booked eight weeks before the auditor's fieldwork, with a testing firm that has a ten-week backlog, is a control that will not be evidenced in time. Build annual-cadence controls into the calendar with their real-world lead time counted backward from when the evidence is actually due — not from when you'd like to start.

Handling exceptions found during self-testing

Finding a control deficiency during your own internal testing is a good outcome — it means the calendar is doing its job. What happens next is where programs either compound the win or squander it. Every exception needs a documented severity, a root cause analysis, a corrective action plan with an owner and due date, and — critically — a note on whether it affects evidence you've already promised covers the full observation period.

Table 13: Exception Severity and Response Thresholds

Track mean time to remediate as a program-level metric across all exceptions — it's one of the clearest indicators to leadership (and eventually to auditors, who often ask about it directly) that the self-testing program is functioning as a real control rather than a paperwork exercise.

Tooling: spreadsheets, GRC platforms, and where each earns its keep

You do not need an expensive GRC platform to run a credible testing calendar in year one. You do need discipline about where evidence lives and how reminders fire. Most organizations move through a predictable tooling progression as their control count and headcount grow.

Table 14: Testing Calendar Tooling Options

Whatever tool you choose, the non-negotiable feature is a dated, timestamped, retained evidence trail per control per cadence instance — not a live dashboard that only shows current state. An auditor sampling August needs to see August's evidence in August's form, not a dashboard that only shows "green" as of today.

Table 15: Approximate Annual Effort by Organization Size

These are illustrative planning figures based on programs we've built, not published benchmarks — use them to size a budget conversation, not as a guarantee.

Common pitfalls that break a testing schedule

Table 16: Testing Calendar Pitfalls and Fixes

"Every broken testing schedule I've ever inherited had the same root cause: it lived in someone's head, or in a spreadsheet only they opened. The fix is never clever — it's just making the calendar boringly, visibly shared." — Dana Whitcombe, GRC Platform Architect, Ledgerline Systems

Case study: Solstice Ledger's recovery, and what changed afterward

Priya's three-week scramble in October ultimately produced clean evidence for the missed months — Solstice's access provisioning control had, in fact, been operating correctly, it just hadn't been evidenced. The auditor accepted reconstructed evidence for two of the three gap months (with a management-response note) but flagged the third as a documented control deficiency in the final report, resolved through a corrective action plan rather than a clean pass. The $2.4 million retail contract still closed — the prospect's security team accepted the qualified note given the fast remediation — but Priya estimates the reconstruction scramble cost roughly 90 person-hours and several very tense weeks that a calendar would have eliminated entirely.

Table 17: Solstice Ledger — Before and After the Testing Calendar

Case study: a healthcare SaaS platform's sampling overhaul

A healthcare technology client — call the company Meridian Health Systems, a clinical scheduling SaaS platform — came to us after their first SOC 2 Type II report drew an unusually high number of auditor sample exceptions: 18% of tested access-review instances failed to show adequate evidence, well above what the audit committee considered acceptable. The root cause wasn't that access reviews weren't happening; it was that the internal team had never applied a consistent internal sample before the auditor's sample arrived, so nobody had visibility into weak spots until fieldwork. We rebuilt their testing calendar with internal sampling mirroring the auditor's expected methodology (Table 6 above), plus a dedicated quarterly internal audit reconciliation step.

Table 18: Meridian Health Systems — Sampling Overhaul Results

Case study: a DevOps-heavy company decentralizing test ownership

A fast-growing developer-tools company — we'll call it Corvid Build, roughly 180 employees at the time — had centralized nearly all control testing under a single compliance analyst, who was drowning in recurring checklist work by month four of their first observation period. We helped Corvid redesign the RACI so that engineering managers owned testing for controls directly tied to their teams (change management, configuration management, access to production), with the compliance function shifting into the Accountable and Consulted role rather than Responsible for every single test.

Table 19: Corvid Build — Decentralization Impact

Decentralizing ownership didn't reduce total effort — it redistributed it to the people closest to the control, who could test and remediate faster than a single centralized reviewer chasing down context from every team.

Connecting the schedule back to your control matrix

A testing calendar and a control matrix should be reconciled against each other at least twice a year — every new or modified control in the matrix needs a corresponding calendar entry, and every calendar entry should trace back to a specific matrix row and criteria point of focus. When these two documents drift apart — a common outcome when the matrix gets updated during a scoping change but nobody tells whoever owns the calendar — you end up either testing controls that no longer exist or, worse, having controls in scope with no testing plan at all.

Table 20: Control Matrix ↔ Testing Calendar Reconciliation Checklist

How internal testing differs from what your external auditor will do

Running your own testing calendar is not a substitute for the external examination — it's preparation for it, and the two exercises use related but distinct techniques. Understanding the difference keeps your internal program honest instead of just performative. Your external auditor's control testing procedures typically combine inquiry (asking the control owner how it works), observation, inspection of evidence, and — for the controls that matter most — re-performance, where the auditor independently redoes the control to confirm the result matches. A walkthrough usually happens once, early in fieldwork, to confirm the auditor's understanding of the process before formal sample selection and testing begins.

Table 22: Internal Self-Testing vs. External Auditor Testing

The practical implication for your calendar: build in a light walkthrough of your own testing process — not just the underlying controls — at least once before the auditor's interim fieldwork. If your internal reviewer can't clearly explain how a control was tested and why the sample was sized the way it was, the auditor's version of that same conversation will surface the same weakness, at a worse time.

Subservice organizations: whose calendar are their controls on?

Not every control your service depends on is one you test yourself. If Solstice Ledger relies on a cloud infrastructure provider for physical data center security, that provider is a subservice organization — and depending on whether your report uses the carve-out method or the inclusive method, your testing calendar treats it very differently. Under the carve-out method (the far more common approach), the subservice organization's controls are excluded from your report entirely; your calendar's job is simply to track that their own attestation (usually their SOC 2 report) is current, request it on a fixed cadence, and review it for anything that affects your risk posture — not to re-test their controls yourself.

Table 23: Testing Calendar Treatment by Subservice Organization Method

This is also where complementary user entity controls show up in reverse — just as your customers have controls they must operate for your system to work as intended, you likely have CUEC-equivalent obligations toward your own subservice organizations. Track those obligations on the same calendar, with the same owner-and-evidence-date discipline as any other control, rather than assuming a vendor contract alone satisfies the requirement. Our vendor management guide goes deeper on structuring the underlying due diligence process this calendar draws from.

Getting control owners to actually follow the calendar

A beautifully designed calendar that control owners quietly ignore is worse than no calendar at all, because it creates false confidence. Adoption is a people problem before it's a process problem, and the fixes that work are unglamorous but effective.

Table 24: Common Adoption Barriers and What Actually Fixes Them

The single most effective lever, in our experience, is the second-to-last row: visibility. A control owner who knows their completion rate shows up on a dashboard the CISO reviews monthly behaves very differently than one who believes nobody's watching until the audit.

First-time Type II periods vs. renewal periods

Your first Type II observation period and every renewal after it are testing calendar exercises, but they carry different risks. In year one, the calendar itself is unproven — you're testing whether the cadence and evidence formats you designed actually work in practice, often while control owners are still learning the process. In renewal years, the risk shifts toward complacency: teams that passed cleanly once assume the calendar will keep running itself, and drift creeps back in exactly the way it did for Solstice before year one's gap.

Table 25: Testing Calendar Priorities, First Period vs. Renewal

If a gap opens between when one Type II period ends and the next begins, your testing calendar for the new period needs to start early enough that the bridge letter covering the interim gap doesn't have to lean on assumptions instead of evidence. And whatever your prior final report noted as an exception, build an explicit calendar checkpoint in the first quarter of the new period to confirm it's genuinely resolved — auditors specifically look for repeat findings across periods, and a testing calendar is the cleanest way to prove one didn't recur.

A 90-day plan to stand up your first testing calendar

If you're starting from nothing — no calendar, no cadence assignments, just a control matrix and an approaching observation period — here's the sequence we walk clients through, compressed into three sprints.

Table 21: 90-Day Testing Calendar Build Plan

Two things matter more than the sequence itself. First, start the clock on long-lead annual controls (penetration tests, DR failover exercises) in the very first sprint — by the time you're 60 days in, an eight-to-twelve-week testing firm backlog will already be biting if you haven't booked it. Second, treat day 90 as a checkpoint, not a finish line: the calendar runs for the full observation period, and the discipline that matters is what happens in month 7, not what happened in week 1.

Evidence discipline built during this 90-day window should connect directly into your broader evidence collection practice, and any changes made to production systems during testing setup should route through your normal change management process rather than being treated as one-off exceptions.

Turning the testing calendar into a business opportunity

It's tempting to treat a testing calendar as pure overhead — a compliance tax that exists to keep an auditor happy once a year. That framing undersells what the calendar actually buys you. A service organization that can produce same-day evidence for any control, for any month, on request isn't just audit-ready; it's sales-ready. Enterprise security reviewers increasingly ask pointed questions about how controls are tested, not just whether they exist, and "we test on a documented schedule with independent internal audit reconciliation" is a materially stronger answer than "we get everything together before the audit." Priya now uses Solstice's testing calendar — anonymized — as a talking point in security questionnaires, and it routinely shortens vendor security review cycles by a week or more.

The same discipline compounds if you're carrying more than one framework. Organizations layering ISO 27001 onto their SOC 2 program — a common move for companies selling into both US and European enterprise buyers — find that a well-built control testing calendar maps almost directly onto ISO 27001's Clause 9.1 monitoring/measurement and Clause 9.2 internal audit requirements, since both frameworks are fundamentally asking the same question: does this control still work, and can you prove it, continuously? If that's on your roadmap, our guides on running ISO 27001 and SOC 2 together and the ISO 27001, SOC 2, and NIST CSF crosswalk walk through where the testing cadences and evidence models overlap, so you're not running two parallel calendars from scratch. If you're still deciding which framework to pursue first, our comparison of how ISO 27001 and SOC 2 differ is a good starting point.

None of this works without leadership treating the calendar as load-bearing rather than optional. The single highest-leverage move we've seen: put testing calendar completion on the same executive dashboard as revenue and uptime metrics. Controls that are visible to leadership get tested on schedule. Controls that live only in a compliance analyst's inbox drift — quietly, and usually right before an auditor's sample lands on the exact month nobody covered.

"The board doesn't want to hear about our testing calendar in the abstract. They want to hear that when a customer asks for August's access review evidence, we hand it to them in an hour, not a week." — Liu Chen, Engineering Manager, Corvid Build

Get your testing calendar audit-ready

Building this calendar from scratch is faster with a starting structure rather than a blank spreadsheet. PentesterWorld's SOC 2 Control Matrix / RACI Template gives you a pre-built cadence and ownership structure you can adapt directly from Table 4 and Table 5 above, and our SOC 2 Gap Analysis Tool helps you sanity-check that every in-scope control actually has a testing plan before your auditor asks. If you're still early in the process, the SOC 2 Readiness Checklist and our SOC 2 Cost Calculator can help you budget the internal hours a calendar like this realistically requires (see Table 15). And if terminology across this article was new to you, bookmark the SOC 2 Glossary — it's the same reference we hand new compliance hires on day one.

A testing calendar won't make your controls better on its own. But it will make sure the good controls you've already built get to prove themselves, every month, for the full window an auditor — and increasingly, your customers — are watching. Build the calendar before the observation period starts, not during month nine.