Every GRC team I've talked with describes their audit prep timeline the same way: planned for 4 weeks, actually took 7, half the time was spent on things that weren't on the original plan. This post isn't a "how to improve your audit prep process" piece — it's an honest description of what the 6 weeks actually contain for a small GRC function running a SOC 2 Type II. If your experience looks different, you're either unusually well-prepared or you have a team size we'd envy.
The team I'm describing is three people: a compliance manager (full-time GRC), a security engineer (GRC is maybe 40% of the role), and an engineering manager who gets pulled in for access reviews, change management artifacts, and policy sign-off (GRC is maybe 10-15% of the role during normal operations, 30-40% during audit season). This is a reasonably typical configuration for a growing SaaS company running their second or third Type II.
We're not saying this timeline is unavoidable — we think continuous monitoring changes it significantly, and we'll note where. But most teams reading this aren't starting from a continuous monitoring baseline, so describing the current state accurately is more useful than describing what it could be.
Week 1: Scope Confirmation and the Discovery of What's Changed
The first week is nominally about confirming scope and starting evidence collection. In practice, it's mostly about discovering how much the environment has changed since the last audit.
The compliance manager starts by reviewing the prior year's system description and identifying areas where the description may no longer match reality. This review typically surfaces three to five meaningful changes: a new AWS region, a replatformed authentication system, a vendor that was added mid-year, a product feature that put a new data type in scope. Each change potentially affects the system description and the control set.
For each identified change, the question is: does the prior year's control design still apply? If authentication moved from a custom-built system to Okta mid-year, the evidence for MFA enforcement changes completely. If a new region was added, CloudTrail coverage in that region needs to be verified — and if it wasn't configured from day one, there's a gap in coverage for the portion of the observation period when the region was running but not monitored.
The security engineer spends week 1 pulling configuration exports from primary systems: IAM policy summaries, CloudTrail region coverage, security group rules, encryption configurations. This is the baseline for the evidence collection that follows.
The gap between what the prior system description says and what the current exports show is the week 1 deliverable. It's rarely empty.
Week 2: Access Review and the First Remediation Backlog
Week 2 is access review week — and for most teams, it's where the plan first starts to slide.
The access review scope typically covers: IAM (direct user permissions plus role assumptions), identity provider (all active accounts and group memberships), primary product database (role-based access), and three to six additional SaaS tools with dedicated admin access. For a 60-80 person company, the access review scope is usually 200-400 accounts across systems.
The compliance manager owns the review coordination. The process: export user lists from each system, cross-reference against the HR system to identify departed employees and role changes since the last review, build the review package, assign manager reviews, track completions, chase non-responses, compile findings.
By end of week 2, the typical finding set includes: 3-8 accounts belonging to departed employees with access not fully revoked, 10-20 accounts where the access level doesn't match the current job role, and 5-10 accounts where the review coverage was incomplete (a manager didn't respond in time, or a system wasn't included in the export).
Each finding opens a remediation ticket. Remediation tickets require someone else to take action — usually an engineer with admin access to the relevant system. Engineering is in sprint planning, not audit prep mode. This is where the first coordination overhead shows up: the GRC team has a list of things that need to happen, and the people who can make them happen have other priorities.
Week 3: Vendor Risk Review and Policy Updates
Week 3 splits between vendor risk and policy review — two tasks that are well-defined in theory and messier in practice.
Vendor risk review means: confirm the subprocessor inventory is current (it usually isn't), collect or confirm current SOC 2 reports for Tier 1 and Tier 2 vendors, and document that you reviewed each report and recorded any exceptions. The subprocessor inventory update typically surfaces at least one vendor that was added during the year without a formal intake, meaning there's no vendor record, no risk tier assignment, and no report on file.
Policy updates are necessary when the environment has changed in ways that make existing policies inaccurate. If you moved to a new identity provider, the access management policy needs to reflect the new system and its configuration. If a new compliance category was added (say, HIPAA requirements now apply to a new product feature), related policies need to be updated and acknowledged. Policy updates require sign-off from the engineering manager and typically from legal or the CEO. Scheduling that sign-off takes time that wasn't in the plan.
Week 4: Evidence Assembly and the Gaps That Require Escalation
Week 4 is evidence assembly: taking the configuration exports, access review records, change management samples, and vendor documents and organizing them into the format the auditor will expect. This is the week that reveals whether the prior three weeks of remediation actually closed the issues found in weeks 2 and 3.
It often doesn't. Remediation tickets that were opened in week 2 are often still open in week 4. The access for the former contractor hasn't been fully revoked because the ticket was assigned to an engineer who has been in customer escalation mode. The new vendor doesn't have a current SOC 2 report because they're ISO 27001 certified but not SOC 2 certified, and the compliance manager is now determining whether that's acceptable and how to document the risk acceptance.
The escalation conversations that happen in week 4 are expensive. They pull in the engineering manager, often the CEO, and sometimes legal. Each conversation requires context that the compliance manager has to provide. Each decision produces a document that needs to be filed as evidence. This is the time sink that never appears in audit prep project plans.
Weeks 5 and 6: Fieldwork Coordination and the Final Evidence Package
Weeks 5 and 6 overlap with auditor fieldwork. For a Type II audit with a 12-month observation window, fieldwork typically runs 2-3 weeks. The GRC team's job during fieldwork is to respond to auditor requests — typically within 24-48 hours — while continuing to close any remaining gaps.
The dynamic during fieldwork is that the auditor is sampling specific dates and asking for specific evidence. "Can you show me the access review records from March 14th?" If the quarterly access review that covered March 14th was completed in April, the records should exist. If the remediation for the flags identified in that review wasn't closed out until June, the auditor will ask about the gap between flagging and remediation.
The final two weeks are operationally stressful in a way that doesn't show up in project plans because the specific evidence requests can't be predicted in advance. You know the general categories; you don't know which dates or which accounts will be sampled. The teams that come through fieldwork cleanest are the ones who can pull any piece of evidence in under five minutes — which requires that evidence was structured as it was generated, not assembled as a trailing activity.
The Time That Wasn't Planned For
Across this six-week window, the unplanned time — the time that accounts for why 4-week plans become 6-week actuals — comes from three sources:
- Cross-functional coordination overhead: Every gap that requires someone outside the GRC team to take action (access removal, policy sign-off, change management documentation) involves scheduling, context transfer, and follow-up. For a small team without a dedicated GRC function, this coordination is the majority of the calendar friction.
- Gap escalations: When a gap is significant enough that it can't be closed before fieldwork, it needs to be escalated, risk-accepted, and documented as a compensating control or management response. These conversations take longer than they should because the context is being assembled during the conversation rather than having been maintained continuously.
- Evidence format problems: Configuration exports that need to be reformatted before they're legible to an auditor, access review records that are in a spreadsheet that doesn't map cleanly to the auditor's evidence request format, vendor risk records that live in an email thread rather than a system of record. Format problems add time even when the underlying evidence is solid.
None of these are avoidable in a world where compliance monitoring happens primarily as a pre-audit activity. The 6 weeks is what it takes because the work is being done all at once rather than distributed across the observation period. The calculus changes when evidence has been accumulating continuously — but that's a different starting point than most teams are working from when they start their third Type II.