The SOC 2 compliance calendar: recurring controls by cadence

Why SOC 2 needs a compliance calendar

Most teams treat their first SOC 2 audit as a project: write the policies, fix the gaps, get the report. Then the second year arrives and they find that much of the work was never a project at all. A large share of SOC 2 controls are recurring: an access review every quarter, a scan review every month, a risk assessment every year. A SOC 2 compliance calendar is simply the list of those recurring controls, with a cadence, an owner and a due date for each, laid out so nothing gets forgotten.

The calendar matters most for a Type 2 report. A Type 1 report looks at whether your controls are designed properly at a point in time. A Type 2 report tests whether they actually operated throughout an observation period, which is commonly 3 to 12 months (your auditor agrees the window with you). If your policy says user access is reviewed quarterly, the auditor will expect evidence of a review for each quarter in that window. A missed quarter can turn into an exception in your report. If you are still deciding which report to go for, see SOC 2 Type 1 vs Type 2.

SOC 2 recurring controls, grouped by cadence

The calendar below has 15 recurring activities: 13 for the Security category, plus a backup restore test and a DR test for Availability. If your scope includes Confidentiality, Processing Integrity or Privacy, your auditor may expect more.

Monthly

• Vulnerability Scan Review. Look at the latest automated scan results, decide what to do about each significant finding, and track fixes against the timeframes in your vulnerability management policy.

Quarterly

• User Access Review. Confirm that only the right people have access to your important systems, and remove what is no longer needed. See how to run a user access review.
• Backup Restore Test. Restore from a real backup and check that the data is complete and usable. A backup you have never restored is a hope, not a control.
• Management Security Review Meeting. A recorded session where leadership reviews security risks, incidents and control gaps, and makes decisions.

Semi-annual

• Asset Inventory Review. Check that the inventory of systems, devices and data stores is accurate and that every asset has an owner.
• Network / Firewall Config Review. Check that firewall rules and other network access controls allow only the traffic the business needs.

Annual

• Risk Assessment. Identify and rate the risks to your commitments, and decide how each one is treated.
• Annual Policy Review. Confirm each policy still matches how you work, has the right owner, and was re-approved where it changed.
• Security Awareness Training. Train everyone and record who completed it.
• Vendor Risk Review. Confirm which vendors you rely on and that their security is still acceptable, for example by collecting their own SOC reports.
• Penetration Test. Have a qualified, independent tester attack your product and infrastructure, then fix what they find.
• Incident Response Tabletop. Walk through a realistic scenario to practise the plan and find its gaps. See how to run an incident response tabletop exercise.
• Business Continuity / DR Test. Prove that critical services can be recovered within your recovery time and recovery point targets.
• Org Chart & Roles Review. Keep reporting lines and security responsibilities defined and current.
• Performance Reviews Completed. Show that every employee was evaluated, including on their security responsibilities.

Event-driven

Some controls are triggered by something happening rather than by the date. They still belong on your calendar as standing procedures, because the auditor will sample them too:

• Onboarding. Background checks where your policy requires them, access granted on approval, and new starters reading and acknowledging the policies that apply to them.
• Offboarding. Access removed promptly when someone leaves, with a record of when. Your quarterly access review is the safety net that catches the ones you missed.
• Policy changes. A new policy version approved by the right person, and employees asked to acknowledge it again when the change affects what they must do. Separately, every policy should get its yearly review even if nothing changed.

What evidence each activity should produce

An activity that happened but left no record did not happen, as far as an audit is concerned. Decide up front what each one produces. Your auditor decides what format and level of detail they accept, so confirm this with them early.

Two habits make this evidence much stronger. Record who did the work and who reviewed it, and keep the evidence for each period separate (one page or folder per quarter, not one document you overwrite). For more on organizing it, see SOC 2 evidence collection.

How to build your SOC 2 annual tasks calendar

Give every activity one owner and a due date

"The security team" is not an owner. Name one person per activity, and if you can, a second person who reviews and signs off the evidence. An independent reviewer is worth having: auditors may question a control where the same person did the work and approved it. Then give every period a concrete due date, not "sometime in Q3".

Anchor on your fiscal year or audit period

Pick one reference year and line every cadence up with it. Many companies use their fiscal year, because budget, performance reviews and board meetings already follow it. If your audit observation period runs on a different cycle, check how the two overlap: each observation window should contain a complete set of the periodic controls your policies promise. Ask your auditor how they treat an annual activity that falls just outside the window.

Spread the annual work

Nine annual activities due in the same month is a recipe for doing all of them badly. Give each one a target month. A sensible order is to start with the risk assessment (it informs what you test and train on), then schedule the vendor review, training, penetration test, DR test and tabletop through the year, and finish with the policy review once the year's changes are known.

Plan notice for the big items

Some activities take weeks to arrange. A penetration test needs a tester booked, a scope agreed and time left to fix the findings before the period ends. A DR test or tabletop needs the right people free on the same day. Start those well ahead of the due date: the due date is when the evidence must be finished, not when the work starts.

Document skips, never just let them lapse

Sometimes a period legitimately does not apply: a system was decommissioned, or nothing changed. That is fine, as long as you record that the period was skipped, who decided it and why, at the time. A period that silently has no evidence looks like a failed control. A period with a written, dated reason looks like a decision.

Avoid the pre-audit scramble

The classic failure is reconstructing a year of evidence in the weeks before fieldwork, with screenshots taken months after the fact. The fix is boring: close each period when it is due, review it, and move on. Check the calendar monthly so overdue items surface while they can still be fixed.

Running the calendar in Confluence

If your team already works in Confluence Cloud, Compliance in a Box creates these recurring activities with the rest of your SOC 2 program (13 with Security only, all 15 when you include Availability) and runs the schedule for you:

• Each activity has a schedule. Monthly, Quarterly, Semi-annual or Annual. Every period is due on its last day, and periods follow the month set in Fiscal year starts in in the company profile, so with an April year start you get periods like FY2027 Q3. Monthly activities use calendar months.
• Evidence pages open on their own. Before each period is due, the app creates an evidence page under the activity page with the period, due date, a checklist of what to provide and a heading for each item. You fill it in and attach your exports.
• Days of notice per activity. The SOC 2 activities start with 14 days and you can set anything from 0 to 90, so you can give a penetration test far more lead time than a scan review.
• Owners, approvers and due dates. Each activity has one owner and one or more approvers. The owner submits the evidence page for approval, and the approval is tied to the exact page version submitted. Self-approval is allowed but flagged.
• My Tasks and reminders. Owners see their open, rejected and overdue periods in My Tasks, and approvers see evidence waiting for them. Reminders arrive as Confluence task notifications when a period opens, 3 days before it is due, and weekly once it is overdue.
• Skip with a reason. A Compliance Admin can skip a period with a written reason. It is never overdue, and who skipped it and why is kept on the activity's page and in the audit log.

Compliance Admins see overdue periods and upcoming due dates on the Dashboard, and each activity's periods, with their approvals and skips, appear in the generated evidence reports. The details are in the user guide chapters on recurring activities and dashboard, tasks and reminders.

FAQ

How often does SOC 2 require a user access review?

SOC 2 does not set a frequency. Quarterly is a common choice for important systems, and whatever you choose should be written in your access control policy. The auditor then checks that you did it as often as you said.

Is a penetration test required for SOC 2?

The criteria do not name a penetration test, but it is a common way to evidence the monitoring and vulnerability criteria (CC4.1 and CC7.1), and many auditors and customers expect one. Confirm with your auditor what they will accept.

What happens if we miss a recurring control?

Do it as soon as you notice, record when it actually happened, and do not backdate anything. In a Type 2 audit a missed period may be reported as an exception. How serious that is depends on the control and is your auditor's call.

Does the calendar matter for a Type 1 report?

Less, because a Type 1 report looks at control design at a point in time. But building the calendar before a Type 1 means you are already producing evidence when your Type 2 observation period starts.

← All articles