The 90-day promise, and what it actually means

"SOC 2 in 90 days" is a common pitch, and it's not wrong — but it describes the readiness sprint for a Type I report, which is a point-in-time assessment of control design.

What has to be true on day one for 90 days to be realistic

You need product and infrastructure that are reasonably stable, at least informal versions of your access-control and change-management practices already in place, and engineering leadership that treats evidence collection as part of the sprint.

Where 90-day timelines actually fail

Almost never on the technical controls. They fail on organisational readiness: nobody owns the vendor risk register, HR onboarding/offboarding isn't documented, or the access review that's "done quarterly" turns out to be an email thread with no artefact.

The honest scoping conversation

Before I'll agree to a 90-day plan with a client, I want to see evidence of at least one control already functioning. If none exist yet, the 90 days needs to include building them — and the timeline should say so up front.

“If a control cannot be evidenced, it does not exist.”