Getting a SOC 2 Report for US Customers: Type 1 vs. Type 2, Auditors, Timeline, and Cost

Key takeaways

• A SOC 2 report is an attestation, not a certification: an independent, licensed CPA firm issues an opinion under the AICPA attestation standards, and you share the report with customers under NDA.
• A SOC 2 Type 1 report covers the design of your controls at a single point in time. A Type 2 report also tests whether they operated over an observation period, typically three months for a first report and twelve months from the second report on.
• From a standing start, a first SOC 2 Type 2 report takes eight to ten months. With an ISO 27001 ISMS already running, readiness shrinks to two to three weeks and the whole project to about five to six months.
• SOC 2 does not require a penetration test. Penetration testing appears only as one example in the points of focus for criterion CC4.1, which are guidance, not requirements.
• Security is the only mandatory Trust Services Criteria category. Most companies scope Security only and add Availability, Confidentiality, or Privacy when a customer contract requires it.

‍

Why a European SaaS Company Suddenly Needs a SOC 2 Report

A European SaaS company signs its first US customer, or gets close to it, and receives a security questionnaire from the buyer's procurement or security team. One of the items asks for a current SOC 2 report. The company may already run an ISMS, sometimes with an ISO 27001 certificate, but the US buyer's vendor risk process is built around SOC 2, and in that process ISO 27001 does not replace it. We cover why US buyers rely on the report, and what it does for a company beyond the first deal, in our overview of the benefits of a SOC 2 report for growing tech companies.

In my projects, the typical company in this situation has 5 to 50 people, most often around 20, runs on AWS, Azure, or GCP, and has not worked with the Trust Services Criteria before the questionnaire arrived. What they need is not an explanation of the standard. They need to know which report to get, who can issue it, how long the customer will wait, and what it costs. That is what this post covers.

SOC 2 Type 1 vs. Type 2: Which One Does the US Customer Expect?

The short answer: ask the buyer. Most US customers want a Type 2, or will settle for a Type 1 as a bridge so the deal can move while the Type 2 is in progress.

The difference is what the auditor gives an opinion on. In a SOC 2 Type 1 report, the auditor assesses whether your controls are suitably designed and in place at a single point in time. In a SOC 2 Type 2 report, the auditor also tests whether those controls operated effectively over a period, usually called the observation or review period. A Type 2 report therefore contains a section with every control, the test the auditor performed, and the result. A Type 1 does not.

What I see from US customers:

• Enterprise procurement teams and anyone with a formal third-party risk program ask for Type 2 and will say so in the contract.
• Most of them accept a Type 1 as a bridge if the Type 2 observation period has already started and you give them a committed date for the Type 2 report. Some accept a signed commitment that you are working toward a Type 2 audit instead.

My recommendation: before deciding anything, ask the buyer which report type they require and which Trust Services Criteria they expect in scope. Their answer sets the project. A Type 1 is a separate engagement with its own fee, and it buys you a few months. If nobody is waiting, those months are better spent inside the Type 2 window.

One vocabulary point, because it comes up in every first call: there is no "SOC 2 certification" and no certificate. SOC 2 is an attestation engagement under the AICPA's attestation standards, SSAE No. 18 with AT-C sections 105 and 205, as the AICPA describes it. The deliverable is a report with an auditor's opinion, and the report is confidential. You share it with customers under NDA, usually through a trust center or on request.

Who Can Issue a SOC 2 Report?

The short answer: a licensed audit firm, and for US customers it matters under which standard that firm signs the opinion.

An opinion under the AICPA attestation standards, examined against the Trust Services Criteria, can only be signed by a CPA firm licensed by a US state board of accountancy, and the firm has to be independent of the company it reports on. Appendix G of the AICPA's SOC 2 guide also allows practitioners outside the US to examine against the same criteria under the international assurance standard, ISAE 3000 (Revised), and report under that standard. In practice this means a German Wirtschaftsprüfer, a Dutch RA, or a UK chartered accountancy firm can issue a report against the Trust Services Criteria. It is not an AICPA SOC 2 report in the strict sense, even if the title says SOC 2.

What nobody else can do: a consultancy, a security vendor, or an ISO certification body cannot sign either kind of opinion, and a "SOC 2 certificate" PDF without an audit firm's examination report behind it is not a SOC 2 report in any form.

For a European company this leaves two routes:

1. A US-licensed CPA firm that works remotely. This is the common case. Several firms specialize in SOC 2 for small and mid-sized SaaS companies, do the whole engagement over video calls and screen sharing, and have no problem with a client in Munich or Vienna.
2. A European audit firm reporting under ISAE 3000 against the Trust Services Criteria. Usually cheaper and closer to home. Works well when the report is mainly for European customers.

How much does the difference matter? For most buyers, not at all. The security analyst or procurement reviewer sees a SOC 2 Type 2 report with a system description, an opinion, control tables, and test results, and does not check whether the opinion paragraph cites AT-C 205 or ISAE 3000. The exception is large US enterprises and regulated sectors such as banking and healthcare, where the vendor-risk policy text says "issued by a licensed CPA firm." There an ISAE-only report can get rejected over a paragraph nobody reads. My rule: clarify this with the potential customer before committing to a SOC 2 report.

What I tell customers to check before signing an engagement letter:

• Under which standard does the firm sign the opinion: the AICPA attestation standards, ISAE 3000, or both? Ask for a sample report and read the opinion page, not just the cover.
• Has the firm issued SOC 2 reports for companies of your size and stack? An auditor used to banks will ask a 20-person SaaS company for evidence that does not exist.
• Who does the fieldwork? Some firms sell under a CPA brand and subcontract the testing. You want to know who you will be talking to for twelve months.
• Does the firm work with your compliance tooling? Auditors who can read evidence straight out of the platform you use save weeks of exports.

One more thing the auditor cannot do: build your controls. Independence rules mean the same firm cannot design your controls and then attest to them. Readiness and audit are two separate engagements, often with two separate parties.

Which Trust Services Criteria Do We Need?

Security, and in most cases only Security, unless the customer specifies otherwise.

The Trust Services Criteria have five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory in every SOC 2 report. Its criteria are called the Common Criteria, CC1 to CC9, and the other four categories are added only if you put them in scope. Engagements that begin in 2027 will generally still use the 2017 criteria with the points of focus revised in 2022. We explain what each category requires, and what the AICPA's draft of new criteria would change from December 31, 2027, in our guide to the SOC 2 Trust Services Criteria.

In my SOC 2 projects, almost every company scopes Security only, and that is what I recommend as a default. The reasons:

• US customers ask for "a SOC 2 report." They rarely specify categories. When they do, it is Security.
• Each additional category adds criteria, adds controls, adds evidence, and extends the audit. Availability, for example, brings in capacity management, backup testing, and recovery objectives that you then have to prove over the full observation period.
• You can add categories in the next report cycle once a customer requires them. You cannot remove a failed criterion from a report that has already been issued.

When it makes sense to add a category from the start:

• Availability, if your contracts carry uptime SLAs and customers audit against them.
• Confidentiality, if you process customer data under strict contractual confidentiality terms, which is common for fintech and legal tech.
• Privacy, rarely requested, but if your company has GDPR processes in place, this category is relatively easy to achieve. It is mostly a matter of mapping your GDPR practices to the criteria.

What Do We Have to Write Ourselves?

A SOC 2 report has four parts: the auditor's opinion, management's assertion, the description of your system, and (in a Type 2) the auditor's tests and results. You, as management, write the system description, and it has to meet the AICPA's description criteria, DC section 200. It explains what the service is, which infrastructure, software, people, procedures, and data it relies on, which controls you operate, which parts of the service are delivered by subservice organizations, and what your customers are expected to do on their side.

There are two decisions in the system description that affect the entire audit:

• Subservice organizations: carve-out or inclusive. Your cloud provider is a subservice organization. With the carve-out method you exclude the provider's controls from your report, name them, and state that you rely on them. With the inclusive method the provider's controls are tested inside your report, which requires the provider's cooperation and is not realistic for a hyperscaler. In my projects I use the carve-out method every time, and I ask customers to list the specific controls they rely on from the provider (physical security, hardware disposal, hypervisor patching) so the auditor sees it was a conscious decision.
• Complementary user entity controls (CUECs). These are the controls your customers have to operate for your controls to work, such as managing their own user accounts in your application. Listing them clearly protects you when a customer blames you for an access issue on their side.

My recommendation is to write the description in the last weeks of readiness, not at the start. By then the policies are written, so most of the description can be pulled straight from them, and you have a clear view of your vendors and systems, which makes the decisions on subservice organization carve-outs and CUECs much easier.

How Long Does a SOC 2 Report Take?

From a standing start to a first Type 2 report in hand: eight to ten months is realistic, made up of three to four months of readiness, a three-month observation period, and the audit itself. With an ISO 27001 certified ISMS already running, readiness is two to three weeks of gap closing and the whole project fits into about five to six months.

The project has three phases, and only one of them can be compressed.

A few things I have learned about the timeline:

• The observation period is the fixed cost. The AICPA standards set no minimum length for a Type 2 period. Six to twelve months is the market norm, and auditors accept a shorter period for a first report. Three months is what we do for a first report: it is the accepted first-time exception and gets a report into the customer's hands quickly. The second report should cover twelve or six months, with no gap between the two periods.
• Readiness is where ISO 27001 pays off. The policies, the risk assessment, the asset inventory, and the access reviews already exist, so readiness is mostly mapping the existing controls to the Common Criteria and closing the gaps the ISO scope did not cover. These typically sit around the COSO-style criteria in CC1 and CC2 (board oversight, organizational structure, internal communication) and around CC9 (vendor risk, business continuity, insurance). On a compliance platform where implementation tasks are shared across frameworks, a company that has completed ISO 27001 has already made most of that progress on SOC 2 without doing anything SOC-specific. What is left is two to three weeks of gap closing, not a second implementation project. We map both frameworks, together with GDPR, to one control set in our comparison of ISO 27001, SOC 2, and GDPR.
• Run an internal check before the window starts, not during it. This is optional, not an audit requirement, but I run a one-day internal audit before the observation period begins: is the control in place, does the evidence it should produce exist, and can it be exported from the system that generates it? Everything found there is fixed before it can become an exception in the report. Finding the same problem four months into the window means either a documented exception or a restarted period.
• The auditor's evidence requests are the schedule risk. A Type 2 fieldwork list for a 20-person SaaS company is long. If the evidence has been collected continuously during the observation period, answering it is a week of work. If it has to be reconstructed, it is a month.

What Does a SOC 2 Audit Cost?

Two budgets: the auditor's fee and your own time. Audit fees vary widely between firms, so compare quotes for the same scope rather than headline prices. A Type 1 on its own is cheaper than a Type 2. What moves the fee is the number of categories in scope, the number of controls and subservice organizations, the length of the observation period, and the quality of the evidence you hand over.

The cost drivers I see most often:

• Scope creep in categories. Adding Availability or Confidentiality because "it looks better" is the most expensive avoidable decision in the project. See above.
• Restarting the observation period. The most expensive outcome of all. It happens when a control is found to be missing or broken halfway through the window and cannot be documented as an isolated exception.

Is a Penetration Test Necessary?

No. SOC 2 does not require a penetration test. None of the Trust Services Criteria requires one; penetration testing appears only as one example in the points of focus for CC4.1, and points of focus are guidance, not requirements. What CC4 and CC7 ask for is that you monitor your controls and identify vulnerabilities, and a pentest is one way of showing that, not the only one. Auditors regularly ask whether you have one, and US customers ask for the executive summary in the same questionnaire that asked for the SOC 2 report. Treat it as a separate decision with its own budget: if customers are asking for it, or you want a strong answer to the vulnerability criteria, run one before the observation period ends and keep the remediation evidence. If nobody is asking, it is not what stands between you and the report.

What to Ask Your Customer before Starting a SOC 2 Audit

If a customer request is what triggers your SOC 2 report, ask that customer these four questions first:

1. Which report type do you need, and by when? Type 1, Type 2, or a Type 1 now with a committed Type 2 later. The date tells you whether paying for a Type 1 as a bridge is worth it.
2. Which Trust Services Criteria do you expect in scope? Most of the time the answer is "a SOC 2 report" and nothing more, which means Security. If they name Availability or Confidentiality, it goes into scope from the start rather than in the second cycle.
3. Does your vendor-risk policy require the opinion to be signed by a licensed CPA firm? This one question decides between a local ISAE 3000 report and a US-licensed CPA firm, and it is cheaper to ask now than to find out from procurement after the report is issued.
4. What else is on the questionnaire? A penetration test summary, a business continuity plan, or a specific policy often sits next to the SOC 2 request. Knowing that early means the observation period produces the evidence for those items too.

How Kertos Supports Your SOC 2 Report

Kertos runs ISO 27001, GDPR, and SOC 2 from a single control set. Implementation tasks are shared across frameworks, so a company that has completed ISO 27001 on Kertos has already done most of the SOC 2 work, and readiness becomes the two to three weeks of gap closing described above rather than a second project. The platform collects evidence from your systems continuously, which is what turns the auditor's Type 2 request list into a week of work instead of a month.

Kertos's certified experts take you through readiness for a Type 1 and a Type 2: scoping the categories, preparing the system description with its carve-outs and CUECs, and running the internal check before the observation period starts. Kaia, the Kertos AI assistant, answers questions about your controls and drafts documents from your own information. The report itself still comes from an independent audit firm of your choice, because the party that helps you build your controls cannot attest to them.

If a US customer has just asked for a SOC 2 report, book a demo and we will show you how much of the work your current setup already covers.

Frequently Asked Questions

Can we get a SOC 2 report in three months because the customer is waiting?

A Type 1, yes, if the controls are already in place or you start from a running ISO 27001 ISMS, where the gap closing takes two to three weeks. A Type 2 in three months is not possible from a standing start, because the observation period alone takes that long after readiness is complete. What usually works is a Type 1 now and a committed Type 2 date in the contract.

Our auditor is in the US. Does the audit happen remotely?

Yes. In my projects the entire engagement, from kickoff to final report, runs over video calls, screen sharing, and the evidence portal. There is no on-site visit for a cloud-native company. Plan for the time difference during fieldwork weeks.

Does a SOC 2 report expire?

The report does not carry an expiry date, but US customers treat a Type 2 report as current for about twelve months after the end of its observation period. The norm is one report per year with consecutive periods and no gap. If your next report is delayed, a bridge letter (also called a gap letter), signed by your management, covers the interval between the end of the last period and the next report.

Is a SOC 2 report with exceptions a problem?

Not necessarily. Exceptions are listed in the tests-and-results section with management's response. An unqualified opinion with a few explained exceptions is normal, and customers are used to reading them. A qualified opinion, where the auditor states that controls in a whole area did not operate effectively, is what you want to avoid, and that is exactly what the internal check before the observation period is for.

Do we have to share the full report with every customer who asks?

No. The report is confidential and shared under NDA. Most companies publish a short summary or a SOC 3 report publicly and send the full SOC 2 report only to customers and prospects who sign an NDA. In practice the report is requested and shared during the buyer's purchasing cycle, as part of the security review before the contract is signed.

Is an ISAE 3000 report the same as a SOC 2 report?

Not quite. A European audit firm can examine your controls against the Trust Services Criteria under ISAE 3000 (Revised), and most buyers will read the result like any SOC 2 report: system description, opinion, controls, and test results. It is not an AICPA SOC 2 report in the strict sense, though, so a buyer whose vendor-risk policy requires a licensed CPA firm can reject it. Ask before you choose the firm.