SOC 2 Type II differs from Type I in one fundamental way: time. The auditor does not just ask whether your controls are well designed; they examine whether those controls operated effectively across an extended period, commonly between six and twelve months. During that window, every sampled instance of a control either has evidence or it does not.
That is why the phrase "evidence window" matters. The moment the observation period begins, your daily operations become the audit trail. Controls that exist only in policy, or that run inconsistently, will produce exceptions.
How the window works
The observation period is chosen by management and agreed with the auditor. It has a start date and an end date. The auditor tests a sample of control operations from within that period. For a quarterly control, they might examine every instance, since there are only a few. For a daily or per-event control, such as approvals for each code change or access provisioning for each new employee, they select samples across the period.
If a control fails during the window, for example a quarterly access review is skipped, the auditor reports an exception. A few well-explained exceptions are survivable; a pattern of them undermines the report.
Before the window opens
Start the observation period only when you are confident controls are operating. Starting too early leads to avoidable exceptions; starting too late delays the report. Use a readiness check to confirm that:
- Policies and procedures are approved, communicated and reflect actual practice.
- Control owners understand their responsibilities and evidence requirements.
- Tooling for evidence collection, such as ticketing, access management, logging and version control, is configured.
- Previous gaps from the readiness assessment are remediated.
- The system description is accurate and agreed.
Typical controls and their evidence
Below are common areas and the type of evidence auditors request.
Access management. New user provisioning approvals, role definitions, terminated user removal within defined timeframes, periodic access reviews with sign-off, privileged access lists, and multi-factor authentication configuration.
Change management. Tickets or pull requests showing authorisation, testing and approval before deployment, with separation between developers and deployers where applicable, and emergency change handling.
Vulnerability and patch management. Scan results, remediation tickets and timelines, penetration test reports and evidence of retesting.
Logging and monitoring. Alert configurations, sample alerts and investigations, log retention evidence and reviews.
Incident response. The incident response plan, records of actual incidents with timelines and post-incident reviews, and evidence of testing such as tabletop exercises.
Backup and recovery. Backup configuration and success reports, and restoration tests.
Vendor management. Vendor inventory, risk assessments, contracts or data processing terms, and reviews of vendor assurance reports such as SOC 2 or ISO certificates.
HR and awareness. Background checks where applicable, signed confidentiality and policy acknowledgments, security awareness training completion, and onboarding and offboarding checklists.
Risk management. Annual risk assessment, risk register updates and management review records.
Governance. Board or leadership oversight of security, policy review and approval records.
Building an evidence-friendly operation
Automate where it is natural. Pull access lists, configuration states and change records directly from systems. Compliance automation platforms can collect evidence continuously, but only if the underlying processes are sound.
Make evidence a by-product of work. For example, require pull requests with approvals for code changes so the record is created automatically. Use ticketing for access requests so approvals are captured.
Keep timestamps and identities clear. Evidence should show who did what and when. Screenshots without dates or context are weak.
Create an evidence calendar. List recurring controls, due dates, owners and storage locations. Send reminders before deadlines.
Review internally before the auditor does. Periodic internal checks, perhaps monthly, catch missed controls early so they can be corrected or documented.
Handling exceptions
Despite best efforts, exceptions happen: a user terminated a day late, a change deployed without a recorded approval, a missed review. When one occurs:
- Document it immediately, with cause and impact.
- Remediate and, where possible, perform a compensating review.
- Strengthen the process to prevent recurrence.
- Be prepared to explain it to the auditor honestly.
Auditors value transparency and corrective action over concealment.
Mid-window changes
Systems and organisations change during the period: new tools, new regions, reorganisations, key staff departures. Keep the auditor informed of significant changes, update the system description and ensure controls continue to operate through transitions.
Timeline planning
Work backwards from the date you need the report. If a customer requires a Type II report by a particular quarter, the observation period must end early enough for fieldwork and report issuance, which can take several weeks. Some companies first obtain Type I to demonstrate commitment while the Type II period runs, then follow with a Type II covering the period.
Mistakes to avoid
- Declaring the window open without confirming controls operate.
- Relying on memory instead of recorded evidence.
- Ignoring small recurring controls, such as monthly reviews, that produce many chances for exceptions.
- Forgetting about subservice organisations and their assurance.
- Letting key evidence owners leave without handover.
Plan your observation period
F9 Infotech helps companies prepare for the evidence window, design controls that generate evidence naturally, run internal checks and liaise with auditors. Plan your observation period with F9 Infotech.
This article is general guidance on SOC 2 practice and does not replace advice from your audit firm.