A SOC 2 audit asks your IT function for eight categories of evidence: user access reviews, documented offboarding, logging and log retention, vulnerability scanning and remediation, change management records, vendor and subservice organization oversight, incident response with proof it was exercised, and security awareness training records. For a Type II report, you have to produce that evidence continuously across an observation window, usually three to twelve months, which is why the honest timeline from a standing start to a first Type II report is six to twelve months, not six weeks.
If a customer just told you they need your SOC 2 report before renewal, the practical first move is to find out which report they actually need and by when, because the answer changes the plan completely.
What is SOC 2, and what is it not?
SOC 2 is an attestation report issued by an independent CPA firm under standards set by the AICPA. An auditor examines the controls you say you have, tests them, and writes an opinion. You receive a report, typically thirty to eighty pages, that you can share with customers under NDA.
What it is not:
It is not a certification. Nobody is “SOC 2 certified.” There is no certificate, no registry, no logo you are entitled to. If a vendor tells you they are SOC 2 certified, they are telling you they have not read their own report. ISO 27001 is a certification. SOC 2 is an attestation.
It is not a checklist you can pass. There is no fixed control list. You define your control environment against the criteria, and the auditor tests what you defined. Two companies with clean SOC 2 reports can have meaningfully different security postures.
It is not SOC 1 or SOC 3. SOC 1 covers controls relevant to a customer’s financial reporting. SOC 3 is a short public-facing summary you can post on a website. SOC 2 is the detailed report about security, and it is the one enterprise procurement asks for.
And it is not something your IT provider can grant you. Only a licensed CPA firm can perform the examination and issue the opinion. An MSP, RJ2 included, can build and operate controls and produce evidence. An MSP cannot audit you and cannot certify you. Anyone who says otherwise is selling something they cannot deliver.
Type I or Type II, and which does your customer want?
Type I tests whether your controls are designed appropriately as of a single date. It is a snapshot. You can get one relatively quickly, and it demonstrates you built the thing.
Type II tests whether those controls actually operated effectively over a period of time. That period, the observation window, is the whole point. The auditor pulls samples from across the window and checks that the control ran every time it was supposed to.
Most enterprise customers want Type II. Some will accept a Type I with a committed date for the Type II to follow, which is the common path for a company doing this for the first time: Type I to unblock the deal, Type II over the following six to twelve months to keep it.
Ask the customer directly. “Type I or Type II, and what observation window are you willing to accept” is a two-line email that can save you four months of building toward the wrong report.
What are the five trust services criteria, and do you need all of them?
The Trust Services Criteria are security, availability, processing integrity, confidentiality, and privacy.
Security is required in every SOC 2. It is referred to as the common criteria, and it covers access control, change management, risk assessment, monitoring, and incident response. The other four are optional and you add them only when your customers or your business model demand it.
Most first-time audits scope to security alone. That is not cutting a corner. It is the standard starting scope, and it is what the majority of reports in circulation cover. Availability makes sense if you sell an uptime commitment. Confidentiality matters if you handle customer data with contractual handling requirements. Processing integrity matters mostly to companies processing transactions on a customer’s behalf. Privacy is the heaviest to add and is usually driven by regulation rather than by a customer request.
Every criterion you add expands the evidence you have to produce, the controls you have to run, and the audit fee. Add them deliberately.
What does the auditor actually ask IT for?
This is the part that lands on the IT team, whether that is one internal person, a co-managed arrangement, or an outside provider. Expect requests in these categories.
User access reviews. A periodic, documented review of who has access to what, who approved it, and what was removed. Quarterly is common. The auditor wants the review artifact with a date and a reviewer name, not a current export of your user list.
Offboarding evidence. For a sample of departures, proof that access was revoked and when. This is where first audits fail most visibly, because the ticket says the account was disabled and nothing records the timestamp, or the person was removed from the domain but kept access to a SaaS app nobody inventoried.
Logging and retention. What is logged, where it goes, how long it is kept, and who reviews it. A stated retention period you cannot demonstrate is worse than a shorter one you can.
Vulnerability management. Scanning on a defined cadence, with findings tracked and remediated inside stated timeframes by severity. The auditor will look at whether you met your own stated timeframes, so do not write “critical within 24 hours” in a policy unless you can hold it.
Change management. Changes to production systems requested, reviewed, approved, and recorded. The auditor pulls a sample of changes and asks for the approval trail on each one.
Vendor management. An inventory of vendors, a risk rating, and evidence you reviewed the security of the ones that matter. For vendors that are subservice organizations, the auditor will want their SOC 2 reports and evidence you actually read them.
Incident response. A documented plan, defined roles, and proof it was exercised, either through a real incident handled per the plan or a tabletop exercise with notes and a date.
Security awareness training. Completion records per employee, per period, including new hires within a stated window of their start date.
Underneath all of it sit written policies, formally approved, with evidence that employees acknowledged them.
How long does a first SOC 2 audit really take?
Plan on six to twelve months from a standing start to a Type II report in hand.
A reasonable breakdown: two to four months of readiness work, closing gaps and getting controls actually running. Then a Type I if you need one, which is weeks not months once readiness is done. Then the Type II observation window, three months at the short end if your auditor accepts it, six or twelve if the customer insists. Then four to eight weeks of fieldwork and report drafting after the window closes.
The window cannot be shortened by working harder. It is elapsed time by definition, which is why the readiness phase is the only place the schedule is genuinely compressible.
What is the most common reason a first attempt drags?
Evidence that does not exist for the period being tested.
The pattern is consistent. A company turns on the right controls, does the work correctly, and then discovers during fieldwork that nothing recorded the work happening. Access was reviewed, but in a meeting with no artifact. Accounts were disabled promptly, but the ticketing system does not show when. Patches went out, but no report ties them to the scanning findings they closed. The control was real and the evidence is not, so the auditor cannot test it, and the observation window effectively restarts from the point the evidence became reliable.
The second most common cause is scope taken on casually. A company adds availability or confidentiality because it sounded good, then spends months building controls no customer ever asked for.
The fix for both is unglamorous: decide the scope narrowly, then instrument the controls so they generate a dated record automatically, before the window opens rather than during it.
What does this look like for a mid-market business in the Chicago area?
The company facing this is usually 50 to 400 people, growing, and has just been told by a large customer or a prospective acquirer that a SOC 2 report is now a condition. There is often no full-time compliance person, and the IT function is either one internal director or a co-managed arrangement. The audit request lands on whoever is closest to the systems.
Around Chicago that means a particular set of companies: professional services and financial firms downtown whose enterprise clients push contractual security requirements down the chain, healthcare-adjacent software companies already carrying HIPAA obligations who now need SOC 2 for a commercial customer, and manufacturers and logistics companies in the Chicago suburbs who signed with a large retailer or OEM and discovered the vendor security questionnaire has teeth.
The division of labor that works: a CPA firm performs the audit, a compliance platform or a consultant runs the readiness program and maps controls, and the IT function builds and operates the technical controls and produces the evidence. RJ2 Technologies works in that third seat. We are not auditors, we cannot certify anyone, and we will tell you plainly which parts of this we can carry and which you need a CPA firm and a compliance advisor for. RJ2 supports SOC 2 Type 2 requirements on the technology side, and our partner specialist provides audit assistance and setup under a separate agreement.
RJ2 has operated in the northwest suburbs since 1998 and is headquartered in Deer Park, Illinois. If a customer has handed you a SOC 2 requirement and you are trying to work out what actually falls on IT, call 847-303-1194 or email sales@rj2t.com.
Related reading: Cyber Security Services and our pillar guide, Cybersecurity for Regulated Industries.
FAQ
Can an MSP make my company SOC 2 compliant?
No. Only a licensed CPA firm can perform a SOC 2 examination and issue the report. An IT provider can build and run the technical controls, keep the evidence in a form an auditor accepts, and answer the auditor’s technical requests. Any provider claiming they can certify you is describing something that does not exist.
What is the difference between SOC 2 Type I and Type II?
Type I tests whether your controls are designed properly on a single date. Type II tests whether they operated effectively across a period, typically three to twelve months. Most enterprise customers want Type II, though many will accept a Type I with a committed date for the Type II that follows.
Do we need all five trust services criteria?
No. Security, the common criteria, is required in every SOC 2. Availability, processing integrity, confidentiality and privacy are optional. Most first-time audits scope to security alone, and each additional criterion adds controls, evidence and audit cost.
How long does a first SOC 2 audit take?
Six to twelve months is realistic from a standing start: two to four months of readiness, then the Type II observation window of three to twelve months, then four to eight weeks of fieldwork and reporting. The observation window is elapsed time and cannot be compressed.
What evidence will the auditor ask IT for?
Access reviews with dates and approvers, offboarding records showing when access was revoked, logging configuration and retention, vulnerability scan results with remediation inside your stated timeframes, change approvals, a vendor inventory with reviews, an incident response plan with proof it was exercised, and training completion records.
Why do first SOC 2 attempts usually run late?
Because the control was running but nothing recorded it running. Access reviews held in meetings with no artifact, account disables with no timestamp, patching with no tie back to the findings it closed. The auditor cannot test what leaves no record, so the observation window restarts from the point the evidence became reliable.