Nine To Twelve Months
Isn't A Guess.
It's What Multi-Cloud SOC 2 Takes.
A realistic month-by-month path to audit-ready, built from engagements across AWS, Azure, and OCI. Most timelines fail from scope creep, not the audit itself.
FIELD NOTE
Six phases tracked across live audit engagements. The observation period alone accounts for a third of the total timeline — and most of the risk.
Multi-Cloud Doesn't Add Complexity. It Multiplies It.
A single-cloud SOC 2 engagement is hard enough. Running the same audit across AWS, Azure, and OCI at once doesn't just add a third more work — it means designing, implementing, and evidencing every control three separate times, on three platforms that were never built to look the same.
The timeline below is built from engagements we've actually run, month by month, including the phases teams consistently underestimate. It isn't the fastest path on paper. It's the one that doesn't force a restart six months in.
The overview below shows all six phases across a realistic twelve-month window — tap any segment to jump straight to it.
Scope & gap assessment
What happens here
The team defines which trust service criteria apply — security, availability, confidentiality, and so on — and inventories every system in scope across AWS, Azure, and OCI, then runs a gap assessment against the SOC 2 control set.
Where it typically slips
Teams under-scope at the start, leaving out a cloud environment or a shadow SaaS tool, and rediscover it mid-implementation — forcing rework on controls that were already considered done.
Keep this phase on schedule
- Inventory every environment in scope before selecting trust service criteria, not after.
- Include shadow IT and SaaS tools that touch in-scope data, not just the three clouds.
- Get gap assessment findings signed off by a named control owner, not just documented.
Control design & policy foundation
What happens here
Security policies get written or updated, control owners are assigned, and controls are designed to work consistently across three cloud platforms that each have their own native tools for identity, logging, and change management.
Where it typically slips
Policies get written generically and don't map cleanly onto any one cloud's actual configuration options, so implementation teams reinterpret them differently per platform — and the controls quietly drift apart before they're even built.
Keep this phase on schedule
- Design controls at the outcome level — "least-privilege access reviewed quarterly" — then map each cloud's native tooling to it separately.
- Assign one control owner per control, not per cloud, so the same person owns consistency across all three.
- Review draft policies against actual cloud configurations before finalizing, not after.
Implementation across clouds
What happens here
Technical controls — identity and access management, logging, encryption, change management — get deployed on AWS, Azure, and OCI. This is where multi-cloud triples the effort of a single-cloud project, because every control needs three separate implementations.
Where it typically slips
Teams implement the easiest cloud first, declare early progress, then discover the other two platforms need meaningfully different approaches — and the schedule was built assuming they wouldn't.
Keep this phase on schedule
- Scope implementation effort per cloud separately from the start; don't assume parity across platforms.
- Implement the hardest cloud environment first, not the easiest — it sets the real pace for the rest.
- Standardize logging and identity formats early so evidence collection doesn't need cloud-specific tooling later.
Evidence automation
What happens here
Instead of manually screenshotting configurations every month across three cloud platforms, the team sets up automated evidence collection — pulling control status directly from each cloud's APIs on a fixed schedule.
Where it typically slips
Teams delay evidence automation because manual collection feels manageable during a short pilot. Then the observation period arrives, and manual evidence collection across three clouds becomes a part-time job nobody budgeted for.
Keep this phase on schedule
- Automate evidence collection before the observation period starts, not during it.
- Centralize evidence from all three clouds into one repository the auditor can review consistently.
- Test the evidence pipeline end-to-end at least once before it needs to run unattended for months.
Observation period
What happens here
For a Type II report, controls have to actually operate — consistently, as designed — for a defined window, usually a minimum of three months. Evidence accumulates continuously across all three clouds throughout this stretch.
Where it typically slips
A single missed control — an access review skipped one month, a logging gap on one cloud — can force the observation period to restart. It's the single most expensive mistake on the entire timeline.
Keep this phase on schedule
- Run a short internal dry-run before the official observation period starts, to catch broken controls early.
- Monitor control operation on a fixed cadence throughout, not just at the end.
- Have a documented remediation process ready so a single missed control doesn't require restarting the whole window.
External audit & report
What happens here
The external auditor tests the evidence, runs walkthroughs with control owners, and issues the final SOC 2 report — assuming the observation period evidence holds up to scrutiny.
Where it typically slips
Control owners who were briefed once at project kickoff aren't prepared to walk an auditor through their control eight months later, and inconsistent answers create audit findings that were entirely avoidable.
Keep this phase on schedule
- Re-brief control owners on their specific controls right before audit fieldwork, not just at kickoff.
- Run a mock walkthrough with each control owner before the real audit conversation.
- Keep a single point of contact coordinating auditor requests across all three cloud teams.
Nothing here is exotic security work.
It's project management applied to three cloud platforms that don't share a console. The nine-to-twelve-month range isn't padding — it's what it actually takes to design, implement, and prove controls consistently across environments that were never built to look the same.
Teams that compress this timeline usually aren't faster. They're skipping the observation-period discipline that makes the report meaningful in the first place.
Not sure where you'd land on this timeline?
Our architects will map your current environment against all six phases and give you a realistic date, not a guess.