SOC 2 Readiness, a Six-Week Freeze, and 23% Unlinked Changes
Corvus Analytics is preparing for its first SOC 2 Type II audit in four months. It has 70 employees, AWS and GitHub, and 14 policies copied from a template. Evidence collection is manual: engineers screenshot the IAM console, export change tickets, and write narratives. A readiness check found 23% of production changes had no linked ticket, 11 former employees still had GitHub access, and six S3 buckets were public for 2-14 days before remediation. The VP of Compliance wants to freeze all production changes for six weeks to clean up before the audit window. Engineering says this will delay a major customer launch. The board wants no repeat findings. The company uses Terraform for 80% of infrastructure and a change-management tool that records approvals but is not connected to deployment.
1. Evaluate the proposed six-week production freeze. What are the consequences, and what should replace it?
Read the worked answer
A six-week freeze is the wrong control for a Type II audit. Type II is about operating effectiveness across the period, not a clean snapshot at the end. Freezing production for six weeks leaves the other ten months unproven, creates a change backlog, and increases pressure for emergency changes that bypass the very controls being tested. It also signals to the auditor that normal operations cannot produce evidence, which is a bigger problem than the exceptions themselves.
Replace the freeze with a risk-based control sprint. Immediately fix the highest-risk items: revoke all former-employee access, remove public bucket permissions, and enable account-level block-public-access with alerting. Then connect the change-management tool to deployment so change records are created automatically from pull requests and Terraform applies. For the 23% unlinked changes, do not fabricate links; sample them, document the cause, and show the new automated linkage plus a retrospective review of the highest-risk changes.
Allow the customer launch to proceed with normal controls. If the launch is high-risk, add a peer review and a rollback plan, not a company-wide freeze. Report to the board that the goal is sustainable evidence, not a quiet audit window.
2. Design an automated evidence and control-monitoring approach for change management, access review, and configuration compliance.
Read the worked answer
For change management, require a change ID in the pull request or commit trailer and have CI reject production deploys without one. Emit deployment events with user, timestamp, commit, approval, and environment to an evidence store. Pull approvals from the change tool through its API and join them to deployment records. Use Terraform plan and apply logs as configuration-change evidence. Sample exceptions monthly rather than screenshotting every change.
For access review, integrate the HR system and IdP as the authoritative joiner-mover-leaver source. Automate deprovisioning on termination, with a daily exception report for active accounts without a matching employee or contractor record. Generate quarterly access-review campaigns from group membership and manager attestation, and retain the attestation records. For GitHub, enforce organization MFA and review outside collaborators separately.
For configuration compliance, use policy-as-code in Terraform and cloud-native config rules to detect public S3 buckets, missing encryption, and overly broad IAM. Route findings to the owning team with a remediation SLA, and retain detection and remediation timestamps as evidence. Build a control dashboard that maps each SOC 2 criterion to an automated test, owner, and last result. Manual narratives remain for judgment areas, but the underlying evidence should be machine-generated and reproducible.
3. How should the exceptions, including the public buckets and former-employee access, be handled in the audit period?
Read the worked answer
Do not hide or backdate the exceptions. Auditors test whether controls operated and whether management detected, responded, and remediated. For the public buckets, document each bucket's data classification, duration of exposure, who had access, whether any access occurred, and the notification decision. If customer data was exposed, follow legal and contractual obligations. Then show the preventive control now in place: account-level public-access block, policy-as-code check, and alerting with an owner.
For the 11 former employees, revoke access immediately, preserve the access logs, and document the offboarding failure. Implement an automated HR-to-IdP-to-GitHub deprovisioning check and a daily exception report. For the 23% unlinked changes, sample the riskiest changes, confirm whether they were reviewed by another human, and document any that were not. Do not retroactively create tickets; that undermines integrity. Instead, present the root cause and the automated linkage control with a post-remediation sample.
Where residual risk remains, use a formal risk acceptance with a business owner, CISO, compensating controls, and an expiry date. Brief the board honestly: the goal is no repeat findings, which requires sustainable controls, not a perfect-looking audit window. An auditor is more likely to accept a documented, remediated exception than an unexplained gap.