SOC 2 Type I vs Type II: Chicago Claims
Chapters
Disclosure: this site is owned and operated by XL.net, a Chicago MSP that is itself ranked here. How we handle that conflict.
What does SOC 2 Type I vs Type II actually mean?
The two reports attest to different things. SOC 2 (System and Organization Controls) Type II is an independent auditor's attestation that a service firm's security controls operated effectively over a multi-month observation period. SOC 2 Type I covers control design at a single point in time.
That distinction matters when a Managed Service Provider (MSP) puts "SOC 2" on a capabilities slide without naming the report type. A buyer reading only the two words cannot tell which of the two sits behind them, and the difference is not cosmetic: one speaks to design at a single point in time, the other to controls operating effectively across a multi-month period.
IT Support Chicago treats Type II as an attestation covering a multi-month observation period, and Type I as covering control design at a single point.
Neither report is a general security grade. We advise treating the words "SOC 2" in a proposal as the start of a question rather than the answer to one: ask the provider which report type was issued, which period it covered, and which systems the engagement looked at.
| Aspect | SOC 2 Type I | SOC 2 Type II |
|---|---|---|
| What it covers | Control design | Whether controls operated effectively |
| Time span | A single point in time | A multi-month observation period |
TL;DR
SOC 2 Type I vs Type II is a difference in what the auditor attested to: Type I covers control design at a single point in time, while Type II is an independent auditor's attestation that controls operated effectively over a multi-month observation period. Among the Chicago firms we track, SOC 2 Type I appears for 11 vendors and SOC 2 Type II for 7, so the report a buyer is more likely to meet is the weaker of the two. Separately, an entry in our table marked as the firm's own claim is one we hold no third-party documentation for — a fact about our records, not a verdict on that firm's security.
- Type I covers control design at a single point in time; Type II covers effective operation over a multi-month observation period.
- In our corpus, Type I entries outnumber Type II entries — 11 vendors against 7.
- An entry marked as the firm's own claim must never be read as certified, audited or accredited.
- One listing can carry several entries all marked as the firm's own claim, so a longer framework list is not proof of more documentation.
- Undocumented claims add 5 points each in our Security Certification criterion, capped at 25 of 100.
Which SOC 2 report shows up more often in our Chicago data?
Type I. Across the 93 active Chicago vendors we track, SOC 2 Type I appears more often than SOC 2 Type II among the framework entries on our listings, which means the more common entry a buyer will meet is the weaker of the two. For context, the most common entries in our records are PCI DSS (Payment Card Industry Data Security Standard) at 20 vendors, CMMC (Cybersecurity Maturity Model Certification) Level 1 at 17 vendors, SOC 2 Type I at 11 vendors, then SOC 2 Type II at 7 vendors and ISO 27001 (International Organization for Standardization) at 7 vendors.
Among the Chicago firms IT Support Chicago tracks, SOC 2 Type I appears for 11 vendors and SOC 2 Type II for 7.
Two caveats govern how those counts may be read. First, they describe the tracked corpus as a whole and say nothing about any individual firm — no single provider can be identified from a distribution. Second, a firm sitting outside one of those counts is a firm we hold no record for on that entry; absence in our records is not evidence that a report does not exist.
Nor does the distribution license an assumption about the provider in front of you: 7 tracked vendors do carry a Type II entry. The practical step for a buyer shortlisting providers is simply to make the question explicit. When a security questionnaire asks about SOC 2 and the provider answers yes, ask them to name the report type in writing rather than inferring it.
What our two documentation marks tell a buyer
Our Certifications column carries exactly two marks, and both describe our records rather than a provider's security posture. A check mark records an entry we hold third-party documentation for — a named third-party issuer's document, evidence hosted off the firm's own domain, or a public registry entry. The wording "(claimed)" records an entry we hold no such documentation for, and we publish that status as the firm's own claim.
IT Support Chicago marks an entry as the firm's own claim when we hold no third-party documentation for it.
An entry with that mark must never be read as certified, audited or accredited. It may well be all three in reality; we simply could not obtain documentation we could stand behind at the time of publication, and our records are the limit of what the mark reports. Treat it as a prompt to ask, not as a finding against the provider.
One more pattern is worth flagging when you read the security frameworks Chicago IT providers list on a single profile: a single listing in our table can carry several framework entries — a SOC 2 Type II entry, an ISO 27001 entry, a CMMC Level 1 entry and a PCI DSS entry — all marked as the firm's own claim at once. A longer list of framework names is therefore not, by itself, evidence of more documentation behind them. Breadth of claims and depth of evidence are separate variables, and our column only ever reports the second one.
How our scoring handles a firm's own undocumented claims
Security Certification is one of the four criteria in our published score and carries a weight of 24 of 100. Third-party documented entries are scored additively by tier. Entries we hold no documentation for are handled differently and deliberately: they still earn credit, but a bounded amount.
In our scoring, IT Support Chicago adds 5 points for each of a firm's own undocumented claims and caps the contribution at 25 of 100.
The cap is the point. Stacking framework names on a website has a ceiling in our score, so a provider cannot climb the Security Certification dimension indefinitely by adding logos to a footer. Across the firms we scored on this criterion, the median is 10.0, the mean is 12.0, and the middle half sits between 5.0 and 20.0, with 83 of 93 firms scored. We would not read a modest Security Certification sub-score as disqualifying on its own — it is one of four criteria, and it reports documentation rather than delivered security.
We walk through the arithmetic and its edge cases in our certification claim scoring guide, and we would add one caution here: a score built from public evidence is a screening instrument, not a security assessment. Certification entries tell you which attestations a firm has put its name to. They do not tell you whether the scope of those attestations covers the systems that matter to your business.
How should you verify a SOC 2 claim yourself?
Ask for the report, not the badge. Put four items in the request: the report type, the name of the auditing firm, the period the attestation covers, and the systems and locations the engagement looked at. If a provider will share only a logo or a summary letter, record that as an open item and keep asking until each of the four is answered in writing.
IT Support Chicago advises buyers to ask for the report itself — the auditor's name, the report type, and the period covered.
Three follow-ups are worth the time. Ask which systems the attestation covers, because what you are checking is whether it reaches the environment the provider would run for you. Ask whether any exceptions were recorded, and what was done about them. And ask when the next report is expected, so you know whether the coverage you are being shown is current. Our certification verification checklist sets out the sequence in full, and we cover what a certification does and does not say about delivered security scope in our piece on scope versus certifications.
One contractual note. Our position is that shorter agreements generally serve the buyer better, and that holds here: if a provider's documentation turns out thinner than the pitch suggested, a short term or a termination-for-convenience clause is a more reliable remedy than any penalty clause you could negotiate in advance. Verification before signature is cheaper still.
Frequently asked questions
Is a SOC 2 Type II report always better than a Type I?
As evidence about how controls behaved, Type II says more: it attests that controls operated effectively over a multi-month observation period, while Type I covers control design at a single point in time. But neither tells you what the engagement covered. Ask which systems each report reaches before ranking the two.
Does a check mark in your Certifications column mean a provider is secure?
No. It means we hold third-party documentation for that entry — an issuer's document, evidence hosted off the firm's own domain, or a public registry entry. It is a statement about our records at the time of publication, never a verdict on a firm's security posture. The same limit applies to entries marked as the firm's own claim.
Should I rule out a provider whose SOC 2 entry is marked as their own claim?
No. The mark records what documentation we could obtain, not what the provider holds. Ask them directly for the report type, the auditor, and the period covered. How completely and how quickly they respond is itself useful signal, and the answer may well resolve the entry in their favour.
Why do you cap the score credit for undocumented certification claims?
Because breadth of claims and depth of evidence are different things. Undocumented claims add 5 points each and are capped at 25 of 100 within Security Certification, so adding framework names to a website reaches a ceiling. Third-party documented entries are the ones scored additively by tier.