A SOC 2 Type 2 report covers a period and includes the auditor's tests of whether controls operated effectively across it. So evidence must exist for the whole period, not just at the end. The calendar below spreads recurring tasks across twelve months and ties each to the Trust Services Criteria it supports.
How long is the period?
The AICPA text we used does not set a minimum length for a Type 2 period. Many organizations choose a length with their auditor, so agree it first. The calendar below uses twelve months because it shows every recurring cycle. If your period is shorter, keep the early months and drop what does not recur within it.
What must run every month?
Monthly tasks create a steady trail.
- Access: list new joiners, movers and leavers with the tickets that granted or removed access (CC6.2, CC6.3). Check that every leaver lost access on time.
- Vulnerabilities: export scan results and show remediation tickets with owners and dates (CC7.1).
- Change: sample pull requests showing review and approval before merge, and the release records (CC8.1).
- Monitoring: show that alerts were reviewed, with a named reviewer and date (CC7.2).
- Management: a short compliance meeting with notes (CC4.1 expects ongoing and separate evaluations).
What goes in each month?
Month 1: baseline. Approve policies, assign owners, record the system description and boundary, and export configuration baselines such as MFA enforcement and branch protection. Start the vendor list.
Month 2: training and onboarding. Complete security awareness training for all staff and keep completion records, plus signed policy acknowledgments (CC1.4, CC2.2).
Month 3: first quarterly access review across every in scope system, signed by the reviewer (CC6.3). Run the first vendor review for critical suppliers (CC9.2).
Month 4: backup restore test with a written result (A1.3, if Availability is in scope). Check that backups for confidential data are encrypted (C1.1).
Month 5: tabletop incident exercise with scenario, participants, decisions and follow ups (CC7.4, CC7.5).
Month 6: second quarterly access review, vulnerability review for the half year, and an interim check of every control against the evidence collected so far. This is your internal dry run.
Month 7: onboarding spot check. Confirm that every person hired since month 1 completed training and acknowledged policies before getting access.
Month 8: risk assessment refresh covering new systems, vendors and threats (CC3.2, CC3.4).
Month 9: third quarterly access review, second vendor review pass, and a recovery plan test if you schedule them twice a year.
Month 10: policy review and re approval where changes are needed, with dated approval. Update the system description for changes made during the period.
Month 11: fourth quarterly access review. Collect auditor request items early: lists of users, changes, incidents and terminations for the whole period.
Month 12: management review of the program, remediation of any exceptions, and a final evidence check by control. Prepare population lists the auditor will sample from.
What do auditors sample?
Auditors typically ask for a full list, such as every change or every leaver, and then pick items to test. So the list itself must be complete and accurate. Export it from the source system, keep the export date, and avoid retyping.
What if a control fails mid period?
Record it, fix it, and keep the record. An exception you identified and corrected is a better story than a gap nobody noticed. Do not alter a policy to match what happened; either perform the control or log the miss.
What to do
- Agree the period length and start date with your auditor.
- Assign an owner to every recurring task in the calendar.
- Put each task in a shared calendar with the evidence it must produce.
- Export baseline configurations in month 1.
- Run quarterly access reviews on the same weeks each quarter.
- Hold the tabletop and restore test on schedule.
- Do an internal dry run at the midpoint.
- Build population lists before the period ends.
Quick check
What is the difference between Type 1 and Type 2?
Type 1 describes the design of controls at a point in time with no opinion on operating effectiveness. Type 2 covers a period and includes tests of operating effectiveness.
Can we collect all the evidence at the end?
Not reliably. Many items, such as access reviews and change approvals, must show they happened during the period.
How Safeguard helps automate this
A twelve month calendar creates hundreds of evidence moments. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs between audits so your team can focus on other work. Technical evidence comes from your real code and dependencies, using scans, SBOMs and reachability, which supports the vulnerability and change months. Autonomous remediation is optional: the agent can open tested fix pull requests, it is off by default, every category starts on Manual, and you choose which run automatically and the approval level. Safeguard helps prepare and keep evidence ready; an independent CPA firm performs the audit. Book a call.
Open the framework mapping demo
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022), criteria CC1.4, CC2.2, CC3.2, CC3.4, CC4.1, CC6.2, CC6.3, CC7.1, CC7.2, CC7.4, CC7.5, CC8.1, CC9.2, A1.3, C1.1, AICPA Trust Services Criteria
Last reviewed: 18 October 2026.
