SOC 2 certification in plain words: what the report is, who is allowed to issue one, and why nobody is SOC 2 certified

Is SOC 2 certification a real thing? Not strictly. SOC 2 is an attestation: a licensed CPA firm examines a company’s controls against the AICPA’s trust services criteria and writes an opinion. You get a report, not a certificate. When a customer asks whether you are SOC 2 certified, they mean: can you send us the report?

SOC 2 certification: what the report actually is

SOC 2 certification is the everyday name for a SOC 2 report: an independent CPA firm’s opinion on a service organization’s controls, judged against the AICPA’s trust services criteria. The report holds the auditor’s opinion, management’s assertion, a system description and the controls, with tests and results in a Type 2. It is a report, not a certificate.

The report is one piece of a wider job. Data maps, deletion requests, contracts with processors and the rest of it sit under how to manage SaaS data compliance, and a SOC 2 request is one part of that work.

The letters come from the profession that writes the report. In the words of the AICPA’s SOC suite of services, System and Organization Controls is “a suite of service offerings CPAs may provide in connection with system-level controls of a service organization or entity-level controls of other organizations”. SOC 2 is the member of that suite that examines a service organization’s description of its system and its controls relevant to security, availability, processing integrity, confidentiality or privacy, as the AICPA’s own guide lists its subject. The firm that signs it has to be a licensed CPA firm, which the section on who is allowed to issue one covers below. You will also see it written as SOC II or SOC 2.0, and SOC II compliance means the same as SOC 2 compliance. When a buyer asks whether you have SOC compliance, the meaning is simple: they are asking whether a SOC report exists. In a job advert or a security team’s org chart, SOC can also mean a security operations center, which is a different thing altogether.

Microsoft’s compliance documentation says plainly who created SOC 2: SOC reports “are internal control reports created by the American Institute of Certified Public Accountants (AICPA)”. The name itself changed in 2017, when the AICPA introduced the term system and organization controls; “Formerly, SOC referred to service organization controls”, so a document that says service organization control reports means the same family under its earlier name. When SOC 2 itself started is not stated on the AICPA’s public pages I read on 3 October 2026.

SOC 2 is not a law and not a framework you install. The AICPA publishes the trust services criteria as control criteria “to evaluate and report on controls”, and the company being examined chooses the controls it uses to meet them. In my reading, that choice is why two SOC 2 reports rarely list the same controls, and why there is no single SOC 2 standard a team can copy. The criteria themselves are numbered, which is where the CC references on a customer’s checklist come from. The system description at the heart of the report is prepared and evaluated against a separate set of AICPA benchmarks, the description criteria.

The everyday meaning of a SOC audit is the examination a CPA firm performs in order to write that report. The SOC 2 for dummies version, in simple terms: the meaning of SOC 2 certification is a report, written by accountants, on how a company protects its customers’ data. Every definition on this page comes from the AICPA’s own pages or a vendor’s documentation, not from a SOC 2 Wikipedia summary or a glossary. Stripe, AWS, Vercel and Supabase give their full SOC 2 reports to customers on request, under an NDA or on certain plans, rather than publishing them; AWS, for one, says “An NDA is required to review the AWS SOC 1 and SOC 2 reports”. Why you cannot download a real one to study is answered in the do I need SOC 2 article linked in the next section.

The AICPA’s key elements of a SOC 2 report page names the parts of the SOC document you receive, and its illustrative Type 2 report “includes management’s assertion, the description of the system, the service auditor’s report and tests of controls and results thereof”. The right-hand column of the table is my reading of what to do with each part when a report lands in your inbox.

What is SOC and SOC 2? What SOC 2 stands for, ‘SOC 2 certified’, and the badge on a website

SOC stands for System and Organization Controls, and SOC 2 is the report on a service organization’s security and related controls. It is an attestation, so nobody is SOC 2 certified. The AICPA’s logo may be used by any service organization that has received a SOC 1, 2 or 3 report from a licensed CPA or a non-U.S. equivalent.

So the SOC 2 full form is System and Organization Controls 2. What SOC stands for in auditing has been the AICPA’s term, system and organization controls, since 2017; before that, the full form was service organization controls. SOC 2 is one report in the family the AICPA calls its SOC suite.

Whether SOC 2 is a certification comes down to who issues it. A certification is issued by a certification body against a standard’s requirements. ISO/IEC 27001, for example, “mandates requirements”, and Microsoft’s cloud is audited against it “by a third-party accredited certification body”. A SOC 2 compliance certification would need a certification body; a SOC 2 report comes from a licensed CPA firm instead. An attestation works the other way round: management makes an assertion about its own system and controls, and a CPA examines it and gives an opinion, which is what the AICPA means by an “Assertion-based examination”. The difference between certification and attestation is the whole reason the phrase “SOC 2 certified” is shorthand. Everyone uses it, and the meaning people intend by SOC certified is that a report exists, but the accurate written phrases are “we have a SOC 2 Type 2 report for the period X to Y” or “we completed a SOC 2 examination”.

A form that asks for a SOC II certification, with a Roman numeral, is asking for the same report. The same logic applies to people: no SOC 2 certification for individuals stands in for a company’s report. The AICPA does offer an Advanced SOC for Service Organizations Certificate, a badge its Credly page says SOC auditors earn by passing a 75-question exam; it speaks to an auditor’s skills, not to any company’s controls. The credential behind a report is the signing firm’s CPA license.

The official SOC badge comes from the AICPA. The AICPA’s logo guidelines for service organizations page says the SOC logos are “designed to help service organizations communicate they have received a SOC report issued by a licensed, independent CPA”. That AICPA SOC logo is the AICPA’s own version of the SOC 2 logo or SOC 2 Type 2 badge a vendor’s website may show. The registration steps and usage rules sit in two PDFs behind a free AICPA account, so I state none of them here. What the AICPA’s logo tells you is that the company has received a SOC report; it does not tell you which period that report covered. So whether a vendor shows a SOC 2 compliance badge, a SOC 2 compliance logo or just a page calling itself SOC 2 compliant, a buyer still asks for the report itself. The nearest thing to a SOC 2 official website is the AICPA’s SOC suite page on aicpa-cima.com.

Why it matters for a small SaaS: what a SOC 2 request is trying to learn

Who asks for a report, what they wrote down and whether any law makes you get one are covered in do I need SOC 2. This section is about what the request is for.

The AICPA’s guide puts the buyer’s side in one sentence: customers and business partners “usually need information about the design, operation, and effectiveness of controls within the service organization’s system”, and to get it they “often request a SOC 2 report from the service organization”. In my reading, every version of the request comes down to one question: has anyone independent examined how you protect the data they hand you?

A security team reads the same document for its security category, which the AICPA’s review checklist describes as information and systems “protected against unauthorized access, unauthorized disclosure of information, and damage to systems”. So when a form says “SOC 2 security compliance” or a reviewer talks about SOC 2 in cyber security terms, they mean the same report, read with that category in mind.

The request reaches you in a few shapes, and the words in it tell you what the reviewer will check. The third column is my reading.

What I would send while there is no report is a short list in the section on how to get SOC 2 certified. The questionnaire itself, row by row, is its own job: a big customer sent a security questionnaire walks through one, and the common standard forms are collected under security questionnaire examples. The short list of controls a buyer expects before any audit has a name of its own, MVSP.

How it works: the report family, the report you are sent, the criteria, the people who sign, and the neighbors

A founder meets these words in roughly this order: which SOC report the customer means, what the dates and letters in the report are, what the criteria cover, who signed it, and how it compares with ISO 27001 and the laws a buyer also names. Each one gets its own part below.

SOC 1 vs SOC 2 vs SOC 3: which report your customer actually means

SOC 1 and SOC 2 answer different questions. The first covers controls relevant to customers’ financial reporting, for them and their auditors. SOC 2 covers security, availability, processing integrity, confidentiality or privacy. A SOC 3 is a general-use report on the same subjects with less detail. A SaaS holding customer data but not their books is in SOC 2 territory.

To define SOC 1 in the AICPA’s words, “SOC 1 is an examination of controls at a service organization that are likely to be relevant to user entities’ internal control over financial reporting”, written for those user entities and “the CPAs that audit the user entities’ financial statements (user auditors)”. Payroll processors and billing engines, anything that feeds a customer’s books, are the usual subjects (my examples). A SOC 2 report covers the trust services subjects listed above and is read by the customer’s security and procurement people, in my reading.

There is a SOC 3 as well: the AICPA’s SOC 2 guide describes SOC 3 engagements as “General-use reports relevant to security, availability, processing integrity, confidentiality, or privacy”. The AICPA’s SOC 3 page adds that they “do not provide the same level of detail” as SOC 2. Platforms publish theirs: “Stripe’s SOC 3 is a public report”, and AWS’s SOC 3 is “publicly available as a whitepaper”. SOC 3 compliance, in the same loose sense as SOC 2 compliance, means a company has a SOC 3 report it can publish; like SOC 2, a SOC 3 certification is in fact a report rather than a certificate.

The three types of SOC reports, side by side:

The readers column for SOC 2 and the last column are my reading. SOC 2 does not cover SOC 1. The difference between SOC 1 and SOC 2 is the subject examined, so one never stands in for the other. A company that needs both runs two examinations; Microsoft, for one, “commissions a full SOC 1 Type 2 and SOC 2 Type 2 examination of Office 365 annually”.

Whether SOC 1 or SOC 2 is harder to achieve has no general answer, in my view. They examine different subjects, so the one your customer names is the one that matters, and the effort depends on the scope chosen rather than on the number. SOC 2 Type 3 and SOC 3 Type 2 are mixed-up names: the AICPA’s vendor-management paper says “there are two types of reports for a SOC 2 engagement”, Type 1 and Type 2, and the Type 1 vs Type 2 guide takes up the Type 3 question in its own FAQ.

A word on SOC 1 for completeness, since its reader is a controller rather than a founder. A SOC 1 report is required, in practice, when a customer’s financial auditors rely on your system for their audit (my reading of the AICPA’s definition above); SOC I is the same report written with a Roman numeral, and in my reading it is a question for billing, payroll and ledger products. SOC 1 comes as a Type 2 too, as Microsoft’s own examination shows, and can be bridged the same way: AWS’s continued operations letter covers both its SOC 1 and SOC 2 reports. The rest of this page stays with SOC 2.

SOC 2 Type 2 certification, the bridge letter, and how to read the report you are sent

A SOC 2 Type 2 certification, as the market says it, is a Type 2 report: an opinion on how controls were designed and operated over the period on the cover. A Type 1 covers design at a single point in time. A bridge letter covers the months after that period; Microsoft calls its own self-attestations, not auditor reports.

Which type to buy is a separate decision, set out in SOC 2 Type 1 vs Type 2, along with how long a report stays useful. Here are the two definitions in the AICPA’s vendor-management paper: a Type 1 examines whether “controls were suitably designed at a point in time”, and a Type 2 also examines “whether controls operated effectively throughout a period of time”. So the SOC 2 Type II certification a buyer asks for is a Type 2 report with a period printed on its cover.

The dates on the cover are the first thing a reviewer reads. The AICPA’s SOC 2 Report Review checklist records the report period as “‘as of’ for type 1, period for type 2”. Whether that period is long enough and recent enough is the reader’s call, and the checklist asks it in those terms: “Does the period of the SOC 2 report cover sufficient period of time and is it recent enough to be useful for our evaluation?” A minimum length for a Type 2 period is not stated on the AICPA’s public pages I read on 3 October 2026.

The bridge letter meaning is simple: it is the document that covers the gap between the end of the last report’s period and today. The same checklist asks, for a report that is not recent enough, “is a bridge letter provided to cover the timing difference?” The vendors that issue them describe them plainly. Microsoft’s bridge letters, “also known as gap letters”, are “self-attestations by Microsoft, not reports based on examinations by the auditor”. AWS calls its version a SOC Continued Operations Letter, “also known as a Bridge Letter”, covering “the period from the date of the last issued SOC report to the date that the COL is published”. So a gap letter, a bridging letter and a bridge letter are one document under three names, and none of them is a SOC 2 report.

No AICPA page I read offers a SOC 2 bridge letter example or template, but going by those two vendors’ descriptions, a bridge letter states roughly this:

• the report it bridges, by name and period end
• the dates the letter covers, from that period end to the letter’s date
• a statement from management about the controls since the period ended
• who signed it, which is the company itself rather than the CPA firm

How to read a SOC 2 report you are sent, in six steps taken from the AICPA’s public review checklist unless marked:

1. 01 Check the report type and the dates: one "as of" date for a Type 1, a start and end date for a Type 2.
2. 02 Read the opinion paragraph first. The checklist lists four types, unmodified, qualified, adverse and disclaimer; a qualified opinion carries the words "except for the effects of the matters giving rise to the modification".
3. 03 Read the system description for its boundaries: which product, which regions, and which subservice organizations are carved out (excluded) from the scope.
4. 04 Scan the tests of controls for exceptions, then find management's response to each one.
5. 05 Read the complementary user entity controls and user entity responsibilities, because those are the vendor's expectations of you.
6. 06 Check the period end against today. My working rule: a report whose period ended more than about a year ago, with no bridge letter, is stale.

Step 4 is easier than it sounds: Microsoft notes that “Management responses to any exceptions are located towards the end of the SOC attestation report”. The six steps are also my answer to how to review a SOC 2 report when you are the customer, and the AICPA’s own SOC 2 report review checklist, offered on its key elements page, is the public reading aid behind them. Step 6 is my rule for reports you receive; how old a report your own buyer will accept is their call. Step 3 is where, in my reading, the SOC 2 system description earns its place: in a SOC2 audit report it is the part that tells you whether the thing you use is inside the examined boundary at all.

The trust services criteria: five categories, and who picks them

The trust services criteria are the AICPA’s yardstick for SOC 2, grouped in five categories: security, availability, processing integrity, confidentiality and privacy. A report may cover any combination of them, and management sets the scope to fit its services. Each category states an outcome, such as information and systems being available for operation, rather than a setting to switch on.

The AICPA trust services criteria are published as the 2017 trust services criteria, revised 2022, which the AICPA describes as control criteria “established by the AICPA’s Assurance Services Executive Committee (ASEC) for use in attestation or consulting engagements”. The criteria text sits behind a free AICPA account, so I quote none of it here.

The review checklist gives each category an outcome, and the table gives all five, close to the checklist’s words.

The checklist makes none of the five compulsory: “SOC 2 reports may include any combination of the following categories. The scoping is determined by management and should reflect the nature of the services provided.” So the 5 trust services criteria categories are a menu rather than a fixed list of SOC 2 certification requirements, and the SOC2 criteria inside each category are what the auditor tests your chosen controls against. The CC references on a customer’s checklist are, in my reading, how the common criteria are numbered; the AICPA’s own checklist uses references such as CC6.2 in its examples. What one numbered criterion means in practice is a question for the guide below.

Why every SOC 2 checklist you find looks different, and what a checklist cannot tell you about your app, are both covered in SOC 2 with no security team. As for the official documents: the criteria are an AICPA download behind a free account, and the SOC 2 guide, the nearest thing to official SOC 2 guidelines, is a paid AICPA publication, so an “AICPA SOC 2 guide PDF” offered on another site is, in my reading, somebody’s copy or summary.

Who is allowed to issue one: the AICPA, SSAE 18, and audit versus attestation

A SOC 2 report is issued by a licensed CPA firm or a non-US equivalent, under the AICPA’s attestation standards, SSAE 18 as amended. SSAE is the CPA’s rulebook, SOC 2 is the report, and the trust services criteria are the yardstick. A consultant, compliance platform or penetration tester can prepare you but cannot sign it.

The AICPA’s review checklist is blunt about it: “Only a licensed CPA firm can issue a valid SOC 2 report”. Its logo page widens that to “a licensed CPA or a non-U.S. equivalent”, the wording in the badge section above. So who can do a SOC 2 audit has one answer: a licensed CPA firm, which people call the SOC 2 auditor. The credential that matters, rather than any personal SOC 2 auditor certification, is the firm’s license, and the checklist tells the reader to check it with the line “CPA firm license current?” When you compare SOC 2 auditors, that license is the first thing to confirm.

SSAE stands for Statements on Standards for Attestation Engagements, which in the words of the AICPA’s list of currently effective SSAEs “are applicable to the preparation and issuance of attestation reports for nonissuers”. The current one is SSAE No. 18, “Attestation Standards: Clarification and Recodification, as amended”, listed as current as of August 2026. Microsoft’s SOC 2 Type 2 attestation “is performed under” SSAE No. 18, and the AICPA’s SOC 2 guide was updated for “SSAE No. 20 and SSAE No. 21”.

SSAE 18 is not the same thing as SOC 2: SSAE 18 is the standard the CPA follows, and SOC 2 is one report written under it, so an SSAE 18 audit or SSAE report usually means a SOC 1 or SOC 2 examination performed under that standard (my reading). The AICPA’s AT-C section 105, which names SSAE No. 18 among its sources, is “Effective for practitioners’ reports dated on or after May 1, 2017, unless otherwise indicated.” The AICPA’s own page says SSAE 18 “recodifies and supersedes” SSAE 10 through 17, except SSAE 15 and a related interpretation.

SAS 70 is the standard that came first. The AICPA’s Journal of Accountancy wrote in 2010 that “Since 1992, Statement on Auditing Standards (SAS) no. 70, Service Organizations, has been the source of the requirements and guidance for CPAs reporting on controls at service organizations”. Those reporting requirements moved into SSAE No. 16, effective for reports for periods ending on or after June 15, 2011, which SSAE 18 later superseded. So SSAE 16 vs SSAE 18 is old versus current. The same article says SSAE 16 is for a CPA reporting on a service organization’s controls “that are relevant to user entities’ internal control over financial reporting”, and that “SAS no. 70 is not applicable to examinations of controls over subject matter other than financial reporting, and neither is SSAE no. 16”. So, in my reading, an SSAE 16 report in an old contract is the forerunner of today’s SOC 1, not of a SOC 2. Nobody is SSAE 18 certified either, for the same reason nobody is SOC 2 certified, and any SSAE certification you are offered is a misnomer in my reading.

Audit versus attestation versus assurance, in my reading of the AICPA’s own usage: the SSAEs govern attestation reports, CPAs “can use the AICPA’s various SOC offerings to provide assurance reports”, and a financial-statement audit is the work of “the CPAs that audit the user entities’ financial statements”. Assurance is the umbrella, attestation is the kind of engagement a SOC report is, and an audit in the strict sense is about financial statements. In attest vs audit terms, then, a SOC 2 report is an attestation built on management’s assertion, while the audit proper is the customer’s financial-statement audit. Even so, people say “SOC 2 audit”, “SOC II audit” or “SOC 2 compliance audit” for the examination, and Microsoft itself writes “examinations (also known as audits)”. SOC2 testing, meaning the tests of controls printed in a Type 2, is the CPA firm’s work, done to that standard.

SOC 2 vs a security audit is a report versus a test: a security audit or code review has no CPA and no attestation opinion, in my reading. If you are looking for a sample letter of attestation of compliance to send a buyer, a letter you write about yourself is a self-attestation, the word Microsoft uses for its own bridge letters, and not a SOC report. Choosing a firm, and the readiness consultants and platforms around them, is covered under SOC 2 compliance consultants; I recommend no firm here.

ISO 27001 vs SOC 2, and where HITRUST, HIPAA, SOX, NIST and PCI sit

ISO 27001 vs SOC 2 comes down to what you receive. ISO 27001 is a standard a company is certified against by an accredited certification body, and what it holds is a certificate. SOC 2 is a CPA firm’s report with no certificate. HIPAA and SOX are US laws, and PCI DSS is the payment card industry’s standard.

ISO/IEC 27001, in Microsoft’s ISO/IEC 27001 page, “is a security standard that formally specifies an Information Security Management System (ISMS)”, and the audit against it is done by the accredited certification body quoted in the section on what SOC 2 stands for. What a company holds at the end is a certificate, as Vercel’s documentation shows when it says “Vercel is ISO 27001:2022 certified” and links its certificate. A SOC 2 examination ends in a report and nothing else.

SOC 2 is not the same as ISO 27001, and in my view neither is better than the other in general. They answer different buyers, and much of the control work behind them overlaps, so the difference between SOC 2 and ISO 27001 is mostly in what you hand over: a certificate against a management-system standard, or a CPA firm’s report on your controls. A team asked for both SOC 2 and ISO 27001 can, in my reading, build one set of controls and evidence it twice. Cost, timeline and the questions an ISO auditor asks are a topic of their own: what ISO 27001 certification costs and what the auditor asks for.

The last column is my reading. The other rows, one at a time. HITRUST describes its CSF as “a comprehensive, threat-adaptive control library harmonizing 60+ frameworks and standards”, and its assurance products “define, assess, and certify security controls”, so HITRUST vs SOC 2 is a certification against HITRUST’s own library versus a CPA’s report. HIPAA is the Health Insurance Portability and Accountability Act of 1996, Public Law 104-191, a US federal law, and Google Cloud’s HIPAA page says HHS “doesn’t offer a certification program for HIPAA compliance”. Whether SOC 2 and HIPAA overlap for your app is the FAQ’s question below, and whether the rule reaches an app at all is set out under whether HIPAA’s rule reaches your app.

SOX is the Sarbanes-Oxley Act of 2002, Public Law 107-204, “An act to protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws”. SOC 2 vs SOX is a report versus a law: SOX touches a SaaS through its customers’ financial auditors, which is the SOC 1 reader from the report-family section, not the SOC 2 reader. (Sox2, with an x and no space, is a gene, not a law.)

SOC 2 is not based on NIST. The trust services criteria are “established by the AICPA’s Assurance Services Executive Committee”, so they are the AICPA’s, not NIST’s, in my reading of that line; any mapping between the two is not covered here. NIST’s Cybersecurity Framework page describes the framework as “Helping organizations to better understand and improve their management of cybersecurity risk”, and whether NIST calls it voluntary or certifies anyone against it is not stated on that page. SOC 2 vs NIST is therefore a report versus a framework.

PCI DSS is maintained by the PCI Security Standards Council, which “was founded in 2006 by American Express, Discover, JCB International, MasterCard and Visa Inc.” A PCI SOC question from a buyer is a card-data question, and which forms apply when Stripe handles the card number is a separate topic: PCI DSS requirements. Nothing in this section is legal advice; HIPAA and SOX are US federal law, and whether either applies to you is a question for a lawyer.

Your platform’s SOC 2 report is not yours: Stripe SOC 2, AWS, Vercel, Supabase and the CUEC page

A platform’s SOC 2 report covers the platform, not the app built on it. Stripe, AWS, Vercel and Supabase each describe SOC 2 reports on their own systems. Such a report can also say what the platform expects of its customers, under complementary user entity controls or user entity responsibilities, such as controlling access to what you run on it.

Supabase says it in one line: “Supabase’s SOC 2 compliance does not transfer to environments outside of the Supabase product or Supabase’s control”. The other platforms say less, but the boundary works the same way in my reading of each vendor’s page. Stripe’s report covers Stripe, not your checkout code. AWS’s covers the AWS services in scope, not your IAM policies. Supabase’s covers the hosted backend, not your row level security policies. Vercel’s covers the deployment platform, not your environment variables; Vercel’s own guide puts it as “The attestation answers the question about Vercel”.

The sources for each row: Stripe’s security documentation says “SOC 1 and SOC 2 Type II reports are produced annually and can be provided upon request” ; AWS’s SOC FAQ lists the SOC 1 and SOC 2 reports as “available to AWS customers from AWS Artifact”, which is also where an Amazon SOC 2 report comes from, and the AWS SOC 3 report as “publicly available as a whitepaper” ; Vercel’s compliance docs state “Vercel has a SOC 2 Type 2 attestation for Security, Confidentiality, and Availability” ; Supabase’s SOC 2 page makes its report available “to Enterprise and Team Plan customers” ; and Microsoft’s SOC 2 offering page points to the Service Trust Portal for its Microsoft cloud SOC 2 reports, the Microsoft Azure SOC 2 Type 2 attestation among them. For each platform’s wider safety and compliance picture, read what Vercel’s certifications actually cover, is Supabase safe and, for Replit, what Replit’s SOC 2 report covers. The same reading applies to a ServiceNow SOC 2 report or any other vendor’s: it describes the vendor’s system.

When you get your own report one day, your host appears in it as a subservice organization. The AICPA’s vendor-management paper speaks of “subservice organizations that provide services on behalf of the vendor” and asks whether they were “included in the scope of the SOC 2 report or excluded”. The review checklist calls the excluded ones “carved out (excluded) from the scope”, and the AICPA’s SOC 1 guide names the two approaches “the inclusive method or the carve-out method”. In my reading, a carve-out audit means the host’s own controls are left out of your report and covered by the host’s report instead; Vercel’s guide describes exactly that, saying that under the carve-out method “your auditor excludes Vercel’s internal controls from your scope”.

The CUEC meaning, in the checklist’s words: complementary user entity controls (CUECs) are “controls that the service organization expects the user entities to implement to enable the service organization to meet its service commitments and/or systems requirements”. The user entity is the customer, which makes you the party assumed to implement complementary user entity controls (CUECs). Some SOC 2 reports have CUECs, but the same checklist says “CUECs should be uncommon in SOC 2 reports”.

User entity responsibilities are the commoner section. The checklist defines them as “activities that must be performed by user entities to derive the intended benefits of using the service organization’s system”, “similar in concept to CUECs but are not required by the service organization to meet its service commitments and/or service requirements”. Microsoft calls them “your control responsibilities necessary if the system as a whole is to meet the SOC 2 control standards”, located “at the very end of the SOC attestation report”. The checklist’s own illustration of one is a customer controlling access to applications and information on an IaaS cloud; that is the AICPA’s example, not a line from any named host’s report. What a given host lists is in that host’s report. In my reading, these user entity controls and responsibilities are the most useful pages of a host’s report for a small team, because they are the host’s own list of what it expects you to do.

Snowflake’s 2024 statement shows where that line falls. Snowflake has a SOC 2 Type II report on its own systems, available on request, which its documentation describes as “an independent auditor’s attestation of the design and operating effectiveness of the security, availability, and confidentiality controls” it had in place during the report’s period. In a community post first published on May 31, 2024 and updated through June 2024, Snowflake and its outside investigators, CrowdStrike and Mandiant, gave their key preliminary findings in a joint statement: they had “not identified evidence suggesting this activity was caused by a vulnerability, misconfiguration, or breach of Snowflake’s platform”; the activity “appears to be a targeted campaign directed at users with single-factor authentication”; and threat actors “have leveraged credentials previously purchased or obtained through infostealing malware”. Its first recommendation to customers was to “Enforce Multi-Factor Authentication on all accounts”. The lesson I take from it is that a platform’s attestation covers the platform: the login settings on your own account were always your control, which is exactly the kind of item a host’s report hands back to its customer under user entity responsibilities or CUECs.

So what may you truthfully write to a buyer whose only SOC 2 in the building belongs to your host? Something like: “Our infrastructure providers hold SOC 2 Type 2 reports, available from them on request (under NDA where the provider requires one, and on the plan it requires); our own application controls are documented here.” What you may not write is “we are SOC 2 compliant because we run on AWS”.

Reviewing each vendor’s report is itself part of SOC 2 vendor management: the AICPA’s vendor-management paper sets out “Identifying and documenting the CUECs that are relevant and applicable to the organization based on the vendor’s SOC 2 report”. Downloading a SOC 2 report from your host works like this: AWS Artifact for AWS, the Service Trust Portal for Microsoft, the Legal Documents section of the organization dashboard for Supabase, the Trust Center or Team Settings for Vercel, and a request for Stripe.

How to get SOC 2 certified: the order of work, and what to say while you have no report

Getting a SOC 2 report runs in 6 steps: set the scope, fix the controls the app enforces, write down the ones that are paperwork, engage a CPA firm, choose a Type 1 date or a Type 2 period, then sit the examination. Until the report exists, say what you have, not what you lack.

To get SOC 2 certification in the loose sense the market uses, the SOC 2 certification process runs in this order:

1. 01 Decide the scope: which product, and which of the five categories. The scoping is determined by management.
2. 02 Fix what the app actually does: the controls that are code, such as access, logging and backups.
3. 03 Write down the controls that are paperwork: policies, reviews, vendor management.
4. 04 Pick a licensed CPA firm and, if you want one, a compliance platform.
5. 05 Choose a Type 1 report as of a date, or go straight to a Type 2 period.
6. 06 Sit the examination and receive the report.

How to get SOC 2 Type 2 certification follows the same order, with step 5 set to a Type 2 period rather than a single date.

To pass a SOC 2 audit, in the sense people mean, is to get an unmodified opinion. No pass mark is written into the report: the firm writes an opinion and prints any exceptions, and the AICPA’s checklist calls an unmodified opinion “the best result of a SOC examination”. The FAQ below covers what the other opinions mean. Durations belong with the do I need SOC 2 question above, every dollar figure lives in SOC 2 cost for a small SaaS, and firms and consultants are a topic of their own, named in the section on who may issue a report. How to prepare for a SOC 2 audit in detail, from a controls list to a booked examination, is set out in the no-security-team guide’s section on getting to SOC 2 compliance from here.

What to send while you have no report, as my working list:

• the completed questionnaire
• a controls checklist with evidence for each row
• your hosts’ reports, with their CUECs and user entity responsibilities answered
• a penetration test summary, if one exists
• a dated statement of what you intend to do and when

What never goes in that reply: “SOC 2 compliant”, “SOC 2 ready” as a claim of outcome, or a logo.

How to check your own app: five things to confirm before you answer the email

Your answer to a SOC 2 request needs 5 things confirmed first: the exact report the customer named, a current report from every provider that holds their data, your side of each provider’s user entity controls and responsibilities, no unbacked claim on your site, and evidence linked to every control you state.

1. 01 Find the exact words in the customer's request: the report type, the period and the categories. Save the message.
2. 02 List every provider that holds customer data and download or request each one's current SOC 2 report or ISO certificate, noting the period end. Fail: a report past about a year with no bridge letter.
3. 03 Open one host's report at its complementary user entity controls and user entity responsibilities and mark each row done or not done in your own account, with a screenshot of the setting. Fail: MFA off on the cloud console, if the list covers account access.
4. 04 Search your own website, deck and questionnaire answers for "SOC 2", "certified" and any logo, and remove any claim you cannot back with a report. Fail: a badge with no report.
5. 05 For every control you claim, point to the person who owns it and the setting or test result that proves it. Fail: a control with nothing behind it.

Some hosts give the report only on some plans, as the platform table above shows for Supabase and Vercel. On a plan that cannot get it, record that and keep the host’s public compliance page instead. The about-a-year limit in check 2 is my working rule, the same one as in the reading steps. For check 3, Microsoft’s page says user entity responsibilities sit near the end of the report, and the AICPA’s vendor-management paper lists “screenshots” among the evidence of CUECs.

Check 5 is the same test the Production Hardening Sprint applies to deliverable 12.6, its SOC 2-style controls checklist, whose verify line reads “Link each documented control to its owner, configuration, or test evidence.” The same line ends: “This deliverable is not a SOC 2 audit report.”

The evidence to keep from the five checks: a dated folder of provider reports, the marked list of CUECs and user entity responsibilities, the before and after of any claim you removed, and the controls list with its links.

Where the sprint fits

Deliverable 12.6, the SOC 2-style controls checklist, delivers “a technical controls checklist with supporting evidence organized for enterprise security review”, verified the way check 5 above describes. Deliverable 13.6, the technical due diligence pack, bundles “the readiness report, architecture diagram, data model, security checklist, and capacity statement into one PDF”. Formal third-party certifications and independent audit opinions are separate from these engineering deliverables, and legal advice and certification are separate services; the sprint implements and documents the technical data-handling controls. Both deliverables are in the published scope.

Common questions about SOC reports

Can you have a SOC 3 without a SOC 2?

Not in the cases on this page: the two platforms here that say what their SOC 3 is based on both build it from the SOC 2 examination. Microsoft says “The SOC 3 report, which is based on the SOC 2 examination, is issued at the same time”, and AWS calls its SOC 3 “a publicly available summary of the AWS SOC 2 report”. The SOC 3 is the general-use report on the same subjects described in the report-family section, and whether one can come from any other examination is not stated on the AICPA’s public pages.

What happens if you fail a SOC audit?

You do not get a fail stamp; you get a weaker opinion and the exceptions printed in the report. The AICPA’s checklist lists four opinions: unmodified, qualified, adverse and disclaimer. A qualified opinion means the auditor “identified material factors affecting the opinion” that were “limited in scope rather than pervasive”; an adverse one means factors “both material and pervasive”. Even an unmodified opinion “does not necessarily mean that there were no exceptions noted, but only that the noted exceptions, if any, did not negatively affect the opinion”. The exceptions sit in the tests of controls, which is where a buyer reads them, so the answer to whether you can fail a SOC 2 audit is that a buyer judges the opinion and the exceptions, not a grade.

Does SOC 2 mean HIPAA compliant?

No. Supabase’s SOC 2 page says “SOC 2 does not cover, nor is it a substitute for, compliance with the Health Insurance Portability and Accountability Act (HIPAA)”. HIPAA, Public Law 104-191, is a US statute, and Google Cloud’s HIPAA page says HHS “doesn’t offer a certification program for HIPAA compliance”. A SOC 2 examination can take on added criteria, and the AICPA’s checklist lists “Additional Criteria (or HIPAA, etc.)” among the scope options, so a SOC 2 Type 2 report can speak to HIPAA-related controls without making anyone HIPAA compliant. HIPAA’s own terms are covered in the HIPAA-readiness guide named above. This is not legal advice.

How often is SOC 2 compliance required?

No cadence is stated on the AICPA’s public pages; in practice, Stripe, Supabase, Microsoft and AWS each report at least once a year. Stripe’s reports are “produced annually”, Supabase’s controls “are fully audited annually”, and Microsoft “commissions a full SOC 1 Type 2 and SOC 2 Type 2 examination of Office 365 annually”. AWS issues its SOC 2 reports “twice per year”, each covering the previous 12 months. How often SOC 2 audits are done for you is set by your contracts, in my reading, and how old a report a buyer accepts is the buyer’s call, as the guide on choosing between the two types notes.

How to check if a company is SOC 2 compliant?

Ask for the report itself, check that a licensed CPA firm signed it, and read the opinion, the period and the exceptions. AWS, for one, requires an NDA before you review its SOC 2 report, and the AICPA’s checklist asks the reader “CPA firm license current?” If the period ended some months ago, ask for a bridge letter. A logo only means the company has received a SOC 1, 2 or 3 report, as the badge section explains; the period it covered is in the report itself.