§5.15 SOC 2 in 120 Days

Abstract. A SOC 2 Type II report attests that controls operated over a period, and the shortest period most audit firms will attest to is three months. That single fact fixes the schedule: get the controls operating by day 30, let the window run to day 120, and accept that the report itself arrives after it. Compliance automation platforms of the Vanta class collapse evidence collection, which used to be the line item that ate the calendar. They do not produce controls, they do not decide scope and they cannot shorten the window. Confidence 0.65. I have operated platforms to ISO 27001, GDPR and Bank Negara Malaysia RMiT, carried them through the security reviews banking and telecom clients run before contract, and worked on compliance alongside partner organisations holding signed Type II reports. I have not owned such a programme end to end. Section 8 says what that distinction is worth.

1. The claim

One hundred and twenty days from a standing start to the close of a SOC 2 Type II observation window, for the Security category, over one product in one cloud account. The work is not hard. The work is arithmetic plus procurement, and almost every plan that slips does so on procurement.

Three things this does not claim.

It does not claim a report in your hand on day 120. The window closes on day 120. Fieldwork overlaps the last month of it, and the signed report follows the close by two to four weeks depending on the firm. Anyone selling you a report on day 120 is selling you a Type I and hoping you do not read the cover page.

It does not claim ISO 27001 on the same schedule. ISO 27001 certifies a management system through a Stage 1 and a Stage 2 audit against an accredited certification body. It is a different object with a different calendar, and the two schedules nest rather than compete.

Claim	Scope	Envelope
Two quarters	ISO 27001 and SOC 2 together, readiness assessment starting in week one, control owners named rather than volunteered.	~180 days
This paper	SOC 2 alone. Security only, one product, one cloud account, one legal entity.	120 days

The outer number is the one I would put in writing to an employer, because it is the one that covers both frameworks and leaves room for the certification body’s calendar. The inner number is what the SOC 2 half of that envelope actually costs, and it is stated separately here so that the outer number can be checked rather than taken. A schedule you cannot decompose is a schedule nobody can hold you to.

It does not claim the controls are good. It claims they are attested. A report says an auditor tested a control and describes what they found. It does not say the control was the right one, and Section 7 is about the distance between those two sentences.

2. What the attestation actually is

Precision here saves a quarter, so it is worth four paragraphs.

A SOC 2 report is written by a licensed CPA firm under AICPA attestation standards. It is not a certificate and there is no certifying body. There is a firm, an opinion and a report with your controls printed in it.

The report is scoped to Trust Services Criteria. Security is mandatory and is the common criteria set. Availability, Confidentiality, Processing Integrity and Privacy are elective, and each one you elect adds controls you must operate and evidence for the life of the company.

Report	What it says	What it costs you in calendar
Type I	The controls were designed appropriately as at one date.	Days, once the controls exist. No window.
Type II	The controls operated effectively across a stated period, tested by sampling that period.	The period. Three months at the floor, twelve at the steady state.

The buyer wants Type II. A Type I buys you a conversation and a line in a questionnaire. It does not close an enterprise security review, because the reviewer’s question is not “did you configure this” but “did you keep doing it”.

3. The arithmetic

Figure 1. The only irreducible segment is the ninety days in the middle, and it is the majority of the schedule. Everything left of day 30 is procurement and configuration, both compressible. Everything right of day 120 belongs to the audit firm. Most plans that slip do so on the two long poles, and neither of them is engineering.

The window is the schedule. Once that is understood, the plan writes itself backwards: the only question that matters in week one is what has to be true on day 30, because the day 30 date is the one that decides the day 120 date.

This inverts the instinct. The instinct is to get the controls right and then start the clock. The correct move is to start the clock at the earliest defensible moment and repair in flight, because a control operating imperfectly for ninety days produces a report with an exception in it, and a perfect control operating for thirty days produces no report at all.

4. What the platform does, and what it does not

Compliance automation platforms are the reason the number is 120 rather than 300. They are also routinely misread as doing the whole job, so both columns matter.

The platform does this	The platform does not do this
Connects to the cloud accounts, identity provider, HR system, endpoint agent, code host and ticket tracker, and reads their state continuously.	Decide what is in scope. Scope is a commercial decision about what you are willing to be audited on, and it belongs to whoever signs the contracts.
Turns each control into a test that passes or fails today, with a timestamp and a history.	Make a failing control pass. A dashboard reporting an unencrypted volume has done its entire job.
Ships policy templates a small company can adopt in an afternoon instead of a month.	Make an adopted policy true. A policy nobody follows is an exception waiting to be written into your report.
Tracks training, policy acknowledgement, background checks and onboarding per person.	Perform your access reviews. Somebody still has to read the list and remove the people who should not be on it.
Hands the auditor a portal with the evidence already assembled. This is the quarter of the project that used to be spent taking screenshots.	Replace the auditor. The opinion is signed by a CPA firm, and the platform is not one.
Keeps a vendor register and chases subprocessor documentation.	Assess the vendor. Collecting a report is not reading it.

Vanta, Drata, Secureframe, Sprinto and the open implementations differ on integration coverage, on how much of the policy set is opinionated, and on whether the auditor relationship is bundled. They do not differ on the line above: all of them automate evidence, none of them automate control.

The choice matters less than the date you make it. Any of them, connected on day 5, beats the best of them connected on day 40.

5. The schedule

Days	Work	Long pole
0 to 10	Scope. Which product, which cloud accounts, which legal entity, which criteria. Security only unless a signed contract already names another category. Control owners named by person, with calendar time allocated.
0 to 10	Engage the audit firm. Book the fieldwork dates before the window opens.	Yes
5 to 20	Connect the platform to everything it can reach. Read the failing list without flinching. Most of it is configuration and most of the configuration is a day's work each.
10 to 30	Close the technical gaps. Multi-factor everywhere, encryption at rest and in transit, log retention set to a number you can defend, backups restored rather than configured, production access reduced to the people who need it.
10 to 30	Close the human gaps. Policies adopted and acknowledged, training assigned, background checks run, onboarding and offboarding that produce a ticket rather than a memory.
20 to 30	Risk assessment and vendor register. Nobody automates these two and auditors read both closely.	Yes
30	Window opens. From this date forward nothing is backfill.
30 to 120	Operate. One access review inside the window, one restore actually executed, one incident response exercise, change management on every merge that reaches production.
90 to 120	Fieldwork. The auditor asks for populations, samples them, and finds the thing you forgot. Answer in days, not weeks.
120	Window closes. Report follows.

Two rows carry the long pole marker and neither is technical. Audit firm capacity is an external dependency you do not control, and the risk assessment is the deliverable that cannot be produced by an integration because it is an argument about your own business.

6. Rules

Normative language, applied to this programme.

6.1. The observation window MUST open before the controls are perfect. Ninety days of an imperfect control produces a report with an exception. Thirty days of a perfect one produces nothing.

6.2. The first report MUST cover Security only, unless a signed contract already names another category. Categories are cheap to add to the second report and expensive to carry through the first.

6.3. Every control MUST have an owner who is a person. A control owned by “engineering” is owned by nobody, and that is discovered in week eleven.

6.4. Evidence SHOULD be a byproduct of work that would happen anyway. An access review that exists only for the auditor will not survive its second year, and the second year is where the exceptions appear.

6.5. The audit firm MUST be engaged before the window opens rather than before it closes. Their capacity is the schedule’s only dependency you cannot buy your way out of late.

6.6. A failing control MUST NOT be closed by narrowing its description until it passes. That is the single move that turns an attestation into a lie. The exceptions section exists so that you never have to make it.

6.7. The platform’s readiness percentage SHOULD be read as a coverage metric rather than a security metric. It measures how much of the estate the platform can see, and it goes down when you connect something new, which is the correct direction.

6.8. Anything the platform cannot reach MUST be written down. The unmanaged laptop, the contractor’s own machine, the legacy virtual machine nobody logs into. An unlisted system is undiscovered rather than out of scope.

7. The named failure mode

Evidence complete, control absent. The dashboard reads green because every automated test passes, and every automated test is a test of configuration. Configuration is the part that automates. The controls that fail in practice are the human ones: an access review performed by clicking approve on a list nobody read, an incident response plan exercised once in week three and never again, a vendor register that stopped being updated in month two.

The tell is timestamps. Work that actually happened is spread across the window. Work that was assembled for the auditor shares a date. A reviewer who has read a hundred of these reports checks the spread before they check the content, and so should you, monthly, while there is still time to fix it.

This is the same failure as the one in paper 5.13, arriving through a different door. A measurement that nobody acts on is not a measurement, and a control that produces evidence without producing a decision is not a control.

8. What I have not done

I have built and operated platforms under ISO 27001, GDPR and Bank Negara Malaysia RMiT requirements for banking and telecom clients, and I have taken those systems through the security reviews and audits those clients run before they will sign.

I have also worked on compliance alongside partner organisations that hold signed SOC 2 Type II reports, which is where the specifics in Sections 4 through 7 come from. That work is real and it is the reason this paper is not theory. It is also not the same thing as having owned the programme: my position in it was a partner’s, contributing to somebody else’s scope, somebody else’s control owners and somebody else’s opinion letter.

The distinction matters enough to print. Working inside a Type II estate teaches you what the evidence looks like, where the sampling bites and which controls fail in month five. Owning the programme end to end teaches you what it costs to be the person who books the firm, sets the scope and signs off the risk assessment. I have the first and I have contributed to the second. That is why the confidence value is 0.65 rather than 0.85, and it moves when the balance changes. This page will say which way and why.

This paper MUST be retracted if any of the following is demonstrated.

§	Condition
1	A SOC 2 Type II report covering an observation window shorter than three months, issued by a firm a mid-market enterprise buyer's security team accepted without qualification. The arithmetic in Section 3 is the only hard constraint this paper claims, and that would remove it.
2	Two comparable companies reaching the same report on the same schedule at similar total cost, one using a compliance automation platform and one not. That would make Section 4 a vendor preference rather than a scheduling argument.
3	Evidence that the exceptions section of a Type II report is not read during enterprise procurement, which would make the failure mode in Section 7 cosmetic.
4	My own first attempt at this schedule slipping for a reason not listed in Section 5. The plan is falsified by the thing it did not anticipate, not by the things it did.

Date	Change
2026-08-31	Section 3 redrawn. The timeline is now a drawn figure rather than an ASCII one, and the proportional bar chart beside it is dropped because the drawing carries the proportions itself. Section 1 gained the envelope table and section 8 was corrected on the author's own evidence. No claim and no confidence value moved.
2026-08-31	First publication. Written as a plan rather than a postmortem, and the abstract says so. Confidence set at 0.65 because the adjacent work is mine and the report is not yet.

Markdown source · JSON index · Atom

SOC 2 in 120 Days

Text