A customer’s form says “SOC 2 Type II”, and you have neither type. They mean the AICPA’s SOC 2 examination, the one a company buying software asks its supplier to produce. Not SOC 1, which the Journal of Accountancy describes as covering the controls likely relevant to a customer’s own financial reporting. Not SOC 3, which the AICPA’s own topic page calls a general use report. Not the accounting sense of those three letters, and not the operations centre a large company staffs around the clock.
This page is for a founder with a working app, no report of either type, and a deal that will not wait while you read a glossary. It sets out what each report says, what it does not say, and what to send back to the person who asked.
Everything below was read rather than performed. The AICPA’s own pages and its own journal were read whole and raw on 3 September 2026 by two different kinds of request, an ordinary one and a browser-imitating one, and every fact here is dated to the day it was read. The ranking vendor pages were read and are named without being linked. Nobody here ran a SOC 2 examination, sat one, sold one, or has seen your report, and nothing here is legal advice, nor a judgement about whether your company or your app meets any standard.
A Type 1 report is an auditor’s report on how controls were designed at one stated date. A Type 2 covers how those same controls ran across a stated stretch of time. Your customer’s “Type II” is the second one. Which of them closes your deal is a question only that customer can answer.
What the two words on your customer’s form mean
The clearest published statement of the difference comes from the two documents the AICPA hands its own members. It publishes an Illustrative Management Representation Letter: SOC 2 Type 1, dated 31 August 2022 on the page, and a separate Illustrative Management Representation Letter: SOC 2 Type 2, dated 21 October 2022. Two report types, two letters, two sets of representations.
Both pages, read on 3 September 2026, state that “AT-C section 205, Assertion-Based Examinations, requires the service auditor to request written representations from the responsible party in a SOC 2 engagement”, and each says its letter includes “additional representations specific to a SOC 2 Type 1 examination” or to “a SOC 2 Type 2 examination” and “should be used for engagements with reports dated on or after June 15, 2022”. The two types are two shapes of the same examination under one standard rather than two products from a vendor, and the AICPA names them with arabic numerals: SOC 2 Type 1 and SOC 2 Type 2. The “Type II” your customer typed is the spelling the market uses.
That naming settles a question a lot of buyers and sellers get wrong in writing. The word the AICPA uses on both of those pages is examination, and what an examination produces is a report. There is no certificate behind it, so “SOC 2 Type 2 certified” is not a status anybody issues. If you want that argument in full, the difference between an attestation and a certificate is set out on the page that answers the same question for a database, and the type-level version is simply this: neither type is a certification, and a supplier who claims one has told you something about their paperwork habits.
One more thing worth knowing before you go looking. Both of those AICPA pages are gated. Each is gated behind a panel that reserves the download to AICPA and CIMA members and offers the PDF only after a member log-in. As of 3 September 2026, in both request shapes, the public part of each page is the description quoted above and nothing further. The detail behind the two report types is published, but it is published to the profession rather than to the buyer or the supplier arguing about it in an email thread.
What a Type 1 report attests, and what it leaves open
A Type 1 speaks about design at a single stated date. An auditor reads the description of the system, reads the controls the company says it operates, and reports on whether those controls were suitably designed to meet the criteria on that date. The date is in the report, and it is the whole of the period the report speaks about.
For a founder in a deal, that is a real document with a real limit. It gives a buyer a described system, a listed set of controls, and an independent report saying the design was examined. It does not say those controls were switched on the week after, because nobody looked. A reader who wants evidence of behaviour over time is asking a question a Type 1 was never built to answer, and no wording in the report pretends otherwise.
That limit is the reason the two types exist at all rather than one. A design opinion and an operating-effectiveness opinion are different jobs, and the AICPA publishes a separate representation letter for each because the company being examined is making different statements in each case. When a buyer says “Type II” and a supplier offers “Type I”, the two sides are talking about two different questions rather than haggling over a grade.
What a Type 1 will not do is tell you whether your customer accepts one. Some buyers have a written policy that names a type. Some accept a Type 1 with a Type 2 to follow and want the follow-up date in the contract. Some do not distinguish at all until an auditor of theirs asks. None of that is knowable from the report or from a page like this one, and guessing it is how a founder ends up paying for the wrong examination. The question belongs to the buyer, and it belongs in writing.
What a Type 2 report adds
A Type 2 speaks about a stated stretch of time that has already elapsed. The same described system and the same control list appear, and beside them sit the tests the auditor performed during that period and what those tests found, including anything that failed. That is the addition: a Type 1 is a statement about a design, and a Type 2 is a record of how the thing behaved while somebody was watching.
| What the report speaks to | SOC 2 Type 1 | SOC 2 Type 2 |
|---|---|---|
| What the auditor examined | how the controls were designed | how the controls ran |
| The time it speaks about | one stated date | one stated stretch of time |
| What a reader finds inside | the boundary drawn around the system, and the controls listed inside it | the same, plus the tests performed and what they found |
| What it says about your own build | nothing outside the boundary the report draws | nothing outside the boundary the report draws |
Every cell there is a property of a document, not a judgement about a company. The table is not a ranking, and it is not an argument that one type is better than the other.
There is a distribution fact underneath all of this that explains why your customer is asking you for the report rather than downloading it. In the Journal of Accountancy article Promises of ‘fast and easy’ threaten SOC credibility, published on 1 February 2026 and written by Andrew Kenney, the magazine states that SOC 2 reports “provide a level of detail sufficient to address the user’s vendor risk management needs and are restricted to specified parties”. Restricted distribution is a feature of the report, which is why it usually arrives under a non-disclosure agreement rather than as a link on a website.
The AICPA’s own SOC 3 topic page, read on 3 September 2026 in both request shapes, draws the same line from the other side: “Like SOC 2, SOC 3 reports address controls relevant to security, availability, processing integrity, confidential and privacy. However, they do not provide the same level of detail. Therefore, they are considered general use reports and can be freely distributed.” The freely distributed one is the one with less in it. The one your customer wants is the one you have to hand over deliberately.
What the AICPA itself is now saying about fast reports
The body that writes the standard behind both report types has spent 2026 publishing about the market that sells them. That record is short, dated, and easy to check, and the measured state of it sits at the end of this section.
Start with the notice the AICPA has posted at the top of its own SOC landing page, read there on 3 September 2026. The body says it is examining anonymous allegations about how one compliance vendor selling SOC services runs its business, and that where auditors involved turn out to have worked outside professional standards, outside peer review, or without a licence, it will act against its own members. The notice names no company, so neither does this page. It also urges that SOC services be weighed carefully both by the organisations buying them and by the CPA firms performing them. Its last line is a pointer to the ethics guidance for firms with business arrangements around SOC tooling.
The February article quoted earlier fills in the background. The Journal of Accountancy, which is the AICPA’s own magazine, writes that SOC reports were “established in 2011” and are “examinations performed by CPAs in accordance with the AICPA’s Statements on Standards for Attestation Engagements to evaluate the controls over customer data that service organizations such as cloud providers or payroll processors have in place”, and that they “provide independent assurance to the service organization’s customers, aka user entities, that those controls are suitably designed and operating effectively”. The same article describes the tool vendors selling around that examination as “now numbering in the dozens” and says some have “aggressively marketed their services in sometimes questionable ways”.
It also carries a line from inside the committee that owns this subject. Sean Linton, CPA/CITP, described on that page as an audit partner at EisnerAmper LLP and chair of the AICPA Assurance Services Executive Committee’s SOC 2 Working Group, is quoted saying that “[SOC] professionals are seeing indications that ‘fast and easy’ may come at the expense of quality and objectivity”.
A founder choosing between a fast report and a slower one is choosing inside a market the standards body has said in public that it is watching.
Three months later the same magazine published AICPA guides peer reviewers to address SOC 2 risks, by Tim Kindem, CPA, on 14 May 2026. It reports that the AICPA’s Peer Review Board issued a May 2026 reviewer alert telling peer reviewers to obtain a deeper understanding of three things: a firm’s use of “external SOC platforms or vendor relationships”, “the reasonableness of SOC 2 engagement timelines”, and “whether engagements are tailored to each client’s specific risks and environment”. The risk it names is work “that have identical reports, risk assessments, sample sizes, and testing procedures”, which peer review labels “nonconforming”. Carl Mayes, CPA, named on that page as vice president for Ethics and Firm Quality at the AICPA, is quoted saying “Some firms are leaning too heavily on third-party SOC platforms without applying the professional judgment required by our standards”.
Now the measured part, which is the reason the definitional answer on this question belongs to companies selling software. The AICPA’s own SOC 2 topic URL, aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2, returned a permanent redirect on 3 September 2026 to its System and Organization Controls: SOC Suite of Services landing page. Read whole and raw on that date, in both request shapes, that landing page’s readable text and its embedded navigation carry no occurrence of “Type 1”, “Type 2”, “Type I” or “Type II” anywhere. The two names appear only inside the page’s own data payload, as the titles of the two member-gated download links quoted earlier. On the same date and in both shapes, the AICPA’s SOC for Service Organizations: Trust Services Criteria resources listing returns “Sorry, nothing matches all of your criteria”.
The three page-one pages that do answer the question were read the same day, whole and raw, in both request shapes: Secureframe’s comparison at secureframe.com/hub/soc-2/type-1-vs-type-2, Vanta’s at vanta.com/collection/soc-2/soc-2-type-1-vs-type-2 and Drata’s help-centre article at help.drata.com/en/articles/8272685-soc-2-type-1-vs-type-2. Across all three, on 3 September 2026, the string “quick-turn” and the name of the AICPA’s own magazine occur zero times, and none of the three cites AT-C. Secureframe’s page raises peer review twice, both times inside its own content payload as advice about how to choose an auditor; Vanta’s and Drata’s pages do not raise it at all. Vanta’s page uses the word “certification” twelve times and does not name the AICPA once. That is a description of what those pages contain, not a judgement of them, and no link to any of them appears here.
Put the record together and it says something useful to a founder rather than to an auditor. Speed is exactly the axis the standards body has decided to watch, the peer reviewers have been told to ask whether a timeline was reasonable, and none of the three ranking pages measured above connects peer review to the timeline a buyer is being sold. That is worth knowing before you sign anything, and it is not a reason to pick either type.
What neither report says about the app you shipped
Every page on this subject is written for the person reading somebody else’s report. If your customer asked you for one, you are on the other side of that now, and the difference matters more than the type does.
A SOC 2 report of either type describes a system, draws a boundary around it, and speaks only about what is inside that boundary. When you are the buyer, the boundary is somebody else’s problem. When you are the supplier, the boundary is a description you sign, and if the application was assembled quickly and nobody has read it end to end, that is the application it will describe. The controls listed inside it are claims about your own software, made by you, before an auditor tests any of them.
That is a different job from reading a vendor’s paperwork. Reading a report that a platform you build on hands to you is the mirror of this, and one page here already sets out what such a report does and does not promise, working through one platform’s trust center line by line.
It is also a different job from having the code looked at. A review of your own application can tell you what is in there before you describe it in a system description, which is useful, and it is not a substitute for an examination by a CPA firm. What a code-level review of your own application can and cannot stand in for is a separate reading, and it is written out elsewhere on this site, including the parts a report will never reach.
Neither type of report, in other words, is a statement that your application is well built. It is a statement about named controls inside a named boundary across a named period. A buyer who reads it carefully knows that. A buyer who does not will find out the first time something inside the boundary behaves differently from the description.
What to write back this week
The useful reply to “we need SOC 2 Type II” is a short list of questions, not a promise. Every line below is something to ask the person who sent the request. None of them is something to answer on their behalf, and none of them has a general answer that holds across buyers.
- Which type gates the deal. Ask whether the contract or their procurement policy names a type, and whether a Type 1 is acceptable at signature with a Type 2 to follow.
- What date they need it by. A date on their side is a fact you can plan against. A vague “before go live” is not.
- Who inside their company decides. Sometimes the request comes from a security team that will read the report, and sometimes from a procurement template nobody has revisited in three years.
- What they will do with it. Restricted distribution is part of the report, so ask what agreement it arrives under and who is allowed to see it.
- What they accept in the meantime. Some buyers take a written description of controls, a completed form, or a contractual commitment while an examination is running. Ask rather than assume.
- Whether anything else on their list carries the same weight. The report type is one line on a list that usually arrives with several others, and the rest of that list has its own answers.
Two of those deserve a note. Asking whether a Type 1 is acceptable at signature is not the same as offering one, and the difference shows in the wording: you are asking what their policy permits, not proposing what you will supply. And the request rarely arrives alone. The report type is usually one row on a longer form, and answering that form the first time is a piece of work in its own right.
Get the answers in writing, in the thread, before you talk to any auditor. A buyer who will not put a type and a date in an email is a buyer whose requirement is still moving, and paying for an examination against a moving requirement is the expensive mistake on this subject.
Where this decision stops and another one starts
This page decides which report a customer’s words point at. Four other questions sit next to it. Each one belongs on a page of its own rather than in a paragraph here.
Whether a report of either type is something you need yet is a question of its own, and it is the one to settle before you pick a type. Related to it, and often confused with it: how long an examination takes to obtain belongs with that question rather than this one, while how long a finished Type 2 report stays useful is a property of the report and is answered below.
What the examination behind either report will cost you is set by the auditor and by whichever tools you buy around it, and the answer belongs on a page that reads their published figures rather than this one. Which of the controls behind either report are code in an application nobody has read is the work rather than the paperwork, and it has its own page.
If the same thread also asked for a test rather than a report, that is a different decision again: whether the auditor or the buyer is asking for a penetration test, and what would satisfy them, is settled on a page of its own. And if one customer says SOC 2 while another says ISO 27001, treat those as two separate requests from two separate buyers and answer each one on its own terms.
Common questions about SOC 2 Type 1 and Type 2 reports
Is a SOC 2 Type 1 a certification?
No. The word the AICPA uses on its own SOC 2 Type 1 page, read on 3 September 2026, is examination, and what an examination produces is a report signed by a CPA firm. No body issues a SOC 2 certificate, so nothing can be held or displayed the way an ISO certificate can. A supplier who writes “SOC 2 Type 1 certified” on a website is describing something that does not exist under that name, which is usually carelessness rather than dishonesty.
What does a SOC 2 Type 1 report actually say?
It says that an auditor examined how a described set of controls was designed, as at one stated date, against the criteria the report names. Inside it a reader finds the description of the system, the boundary drawn around it, the controls listed inside that boundary, and the auditor’s report. It says nothing about how those controls behaved on any other day, because a Type 1 examination does not look at any other day.
Is “Type II” the same as “Type 2”?
Yes. The AICPA writes both types with arabic numerals on its own pages, which are titled “Illustrative Management Representation Letter: SOC 2 Type 1” and “Illustrative Management Representation Letter: SOC 2 Type 2”, read 3 September 2026. “Type II” is the roman-numeral spelling the market settled on, and it is what most customers type into a form. Nobody is describing a different document.
Will a customer accept a Type 1 while a Type 2 is running?
Only that customer can tell you. Acceptance is a policy question inside the buyer’s company, not a property of either report, and buyers differ: some name a type in the contract, some accept a Type 1 with a dated commitment to a Type 2, some never look closely. Ask them directly, in the thread, and ask for the answer in writing before you commit to an examination.
How long is a SOC 2 Type 2 report still useful for?
A Type 2 report does not expire, because nothing issues it a date to expire on. What ages is the period it covers: the report speaks about a stretch of time that ended when it ended, and every month after that is a month nobody examined. Across the five AICPA pages read whole and raw for this article on 3 September 2026, in both request shapes, no expiry rule for a report appears at all. In practice the buyer’s own tolerance decides, which is another question to ask them rather than answer for them.
Does a Type 2 report cover the application my customer will log into?
Only if that application sits inside the boundary the report describes. A SOC 2 report of either type speaks about a named system and the controls listed inside it, and anything outside that description is simply not addressed. This is the point buyers most often miss when a supplier forwards a platform’s report instead of their own: the platform’s boundary is the platform, not the software you built on top of it.
Is a Type 2 more work than a Type 1?
For the auditor, yes, and the mechanism is visible in what each report contains. A Type 2 covers a stretch of time and carries the tests performed during it along with what those tests found, while a Type 1 reports on design at a single date and carries no test results. More looking means more auditor hours. What any particular firm then charges is a separate matter, and no honest figure exists in the abstract.
What either report costs to obtain is priced by auditors and compliance vendors rather than by AxonBuild, and those figures sit on their own page.
Is there a SOC 2 Type 3?
No. The AICPA publishes representation letters for a SOC 2 Type 1 and a SOC 2 Type 2 and for no third type, verified across the five AICPA pages read whole and raw for this article on 3 September 2026. What does exist is SOC 3, a different report in the same suite: the AICPA’s SOC 3 topic page, read the same day, says such reports “address controls relevant to security, availability, processing integrity, confidential and privacy” like SOC 2 but “do not provide the same level of detail”, which is why they “can be freely distributed”.
If you have a working app built with these tools and need it ready for real customers, this is what we do.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase