Industry16 June 2026 7 min read

Building an Annual SOC 2 Compliance Programme

SOC 2 is not a one-time project. Build a sustainable annual programme with the right calendar, ownership, and automation to maintain compliance year-round.

Key Takeaways

The annual SOC 2 cycle: preparation → observation period → auditor fieldwork → report delivery → preparation again.
Most compliance work happens in the observation period — not just before the audit.
A programme calendar with recurring events prevents the end-of-period scramble.
Annual audit renewal costs are typically 70–80% of the initial engagement.
The most mature programmes run compliance continuously — audit preparation is just a lighter-touch review of ongoing work.

In this guide

The Annual SOC 2 Cycle
Programme Calendar
Ongoing Programme Activities
Annual Audit Preparation
Continuous Improvement
Scaling the Programme

The Annual SOC 2 Cycle

A SOC 2 Type II programme runs on a continuous annual cycle. After your first Type II report, the cycle repeats: the observation period for your next report begins where the previous one ended. Fieldwork for your Year 2 report typically begins 2–3 months before the observation period end date.

Many companies align their SOC 2 observation period with their fiscal year or calendar year for simplicity. Others align with their annual risk assessment cycle. Discuss the period with your auditor at the start of each engagement.

Programme Calendar

Build a recurring annual calendar with these scheduled events: Q1 — annual risk assessment, policy review cycle begins. Q2 — policy updates approved, security awareness training cycle. Q3 — penetration test conducted, access review (Q2 and Q3). Q4 — observation period summary review, vendor review cycle, audit preparation begins.

Monthly recurring: access review for high-risk systems, Security Hub export for evidence, vulnerability scan review and tracking.

Weekly automated: Security Hub compliance score snapshot, IAM credential report, GuardDuty summary — all automated via EventBridge Lambda pipeline.

Event-triggered: change management ticket for every production deployment, incident ticket for every security event above P3, vendor review for every new Tier 1 vendor onboarding.

Ongoing Programme Activities

Evidence collection: continuous via automation for infrastructure controls, event-triggered for operational controls, scheduled for periodic controls. Evidence should accumulate automatically throughout the year — not be collected in the 6 weeks before audit fieldwork.

Control monitoring: review Security Hub findings weekly for regressions. Address exceptions within the SLA defined in your Vulnerability Management Policy. Document remediation.

Policy maintenance: review policies when significant changes occur (new tools, changed processes, new regulatory requirements). Formal annual review with approval update. Track acknowledgements for new joiners.

Vendor management: add new Tier 1 vendors to the vendor register before onboarding, download annual SOC 2 report renewals from major vendors, conduct full Tier 1 vendor review annually.

Annual Audit Preparation

8 weeks before fieldwork: complete the pre-audit evidence review. Check every control: is there evidence for the full observation period? Identify and address gaps. Brief control owners.

4 weeks before fieldwork: confirm auditor scheduling, review and update the system description document, ensure all policy documents are current and approved, and prepare a summary of any significant changes since the previous audit.

2 weeks before fieldwork: brief engineering and operations team on audit timing and their role. Review common auditor questions and how to answer them. Confirm evidence is organised and accessible in the compliance tool.

During fieldwork: respond to PBC requests within 1–2 business days, be available for control walkthrough interviews, and communicate proactively if any evidence gap is discovered.

Continuous Improvement

After each audit: review the exceptions (if any) for root cause and pattern. Implement permanent fixes. Update policies and controls to prevent recurrence. Add new controls if emerging threats or business changes create new risk areas.

Track programme metrics year over year: number of exceptions, control coverage percentage, average time to remediate Security Hub findings, employee security training completion rate. A programme that improves on these metrics annually is a healthy programme.

Annual scope review: consider whether additional Trust Services Criteria should be added. Availability is the most common addition after initial Security-only programmes. Confidentiality is worth adding if you handle highly sensitive data.

Scaling the Programme

As your company grows, the compliance programme must scale. Key scaling triggers: 50+ employees (add a dedicated Security/Compliance function), 100+ employees (hire a GRC specialist alongside security engineers), 200+ employees (consider adding ISO 27001 alongside SOC 2 for European market expansion), acquisition or significant architectural change (re-scope the programme).

Multi-framework expansion: companies that start with SOC 2 often add ISO 27001 for European sales, DPDP Act for Indian regulatory compliance, and potentially HIPAA or PCI DSS for sector-specific requirements. A unified control framework makes each new framework an incremental addition rather than a new programme.

The compliance programme should grow with the company — but it should also become more efficient over time as automation handles more evidence collection and the team develops institutional knowledge of the control environment.

Frequently Asked Questions

How much does the annual SOC 2 renewal audit cost?

Renewal audit fees are typically 70–80% of the initial engagement cost. If your first Type II engagement cost $25,000, expect $17,500–$20,000 for annual renewals. The reduction reflects that the auditor already understands your system and does not need to perform the same level of initial documentation review.

Can we reduce our SOC 2 scope over time?

Yes, though reducing scope is unusual. More common: expanding scope (adding Trust Services Criteria, adding new systems to scope) as the business grows. If a product is discontinued or a significant portion of your business changes, discuss scope adjustment with your auditor — you may be able to reduce the scope of the observation period.

What happens if we miss our annual audit and our report lapses?

Your SOC 2 report becomes stale (more than 12 months old). Enterprise prospects who ask for a current report will note it is outdated. You can still conduct a new audit, but there may be a gap period without a current report. Most auditors recommend beginning fieldwork planning 3 months before your desired report end date to avoid gaps.

How do we handle a major architecture change during the observation period?

Inform your auditor immediately. Major changes (migrating from AWS to GCP, significant new product features affecting the system description) require updating the system description and may require adjusting the scope of the audit. Proactive communication with your auditor prevents surprises in the report.

What is the most common reason companies abandon their SOC 2 programme?

Leadership change (new CTO who does not prioritise it), cost cutting during difficult business periods, or underestimating the ongoing time commitment and making no provisions for it in headcount. Building the programme into standard operational procedures and team OKRs (not a special project) is the most effective way to ensure continuity.