What a SOC 2 report is, and who issues it
SOC 2 is a reporting framework created by the American Institute of Certified Public Accountants (AICPA). A service organisation, typically a SaaS company, a cloud provider or a managed service provider, engages an independent CPA firm to examine its controls against the AICPA Trust Services Criteria. The result is a report that the organisation shares with customers who need assurance about how their data is handled.
The report has a fixed shape. It contains the auditor's opinion, a written assertion signed by the organisation's management, a description of the system in scope, and the controls mapped to the criteria. In a Type II report there is one more section: a description of the tests the auditor performed on each control and the results, including any exceptions found. That extra section is where most of the difference between the two types lives.
Attestation, not certification
SOC 2 is an attestation, not a certification. Nobody receives a SOC 2 certificate. What the organisation receives is an auditor's opinion on whether its description of the system is fair and whether its controls meet the criteria, stated in the report itself. There is no pass mark and no seal. A report can carry a clean (unqualified) opinion, or a qualified opinion when the auditor finds that certain criteria were not met.
This matters when a customer asks "are you SOC 2 certified?". The accurate answer is "we have a SOC 2 Type II report covering this period, issued by this firm". Procurement and security reviewers who know the framework read the period, the scope and the opinion, not a badge.
The Trust Services Criteria in scope
The criteria are grouped into five categories: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security, also called the common criteria, is included in every SOC 2 examination. The other four are added depending on what the organisation has committed to its customers. A payments platform with uptime commitments might add Availability; a company handling confidential client documents might add Confidentiality.
Scope is a decision with consequences. Every category added brings more criteria, more controls and more evidence to produce throughout the period. The SOC 2 Trust Services Criteria explained post covers each category in detail. For the purposes of Type I versus Type II, the important point is that the criteria are the same in both report types. What changes is how deeply the auditor tests against them.
What a Type I report tests
A Type I report answers one question: as of a specific date, were the organisation's controls suitably designed to meet the criteria, and had they been implemented? The auditor picks no period. They look at the system and the controls as they stand on that date, often called the "as of" date, and form an opinion.
To do this, the auditor reviews the system description, walks through each control with the people who operate it, and inspects enough documentation to confirm the control exists and would meet the criteria if it ran as described. A policy requiring quarterly access reviews, a documented review procedure and evidence that the tooling is in place may be enough for a Type I. Whether the review was actually performed every quarter is not the question.
Design of controls at a single date
Design means the control, as written and set up, would address the risk the criterion describes. An access review control is well designed if it names who reviews, what systems are covered, how often, what happens with inappropriate access and where the outcome is recorded. A control that says "access is reviewed periodically" with no owner, frequency or record is poorly designed, and a Type I auditor will flag it.
This makes a Type I useful as a structured check of the programme before anyone has a track record to test. Gaps in scope, missing controls and vague procedures surface early, when they are cheapest to fix. Many organisations treat the Type I as a readiness milestone on the way to a Type II rather than a goal in itself.
What the auditor reviews
In practice a Type I examination covers the system description (infrastructure, software, people, procedures and data), the management assertion, and each control's design and implementation. The auditor will typically ask for policies, configuration screenshots, process documentation and interviews with control owners.
What the auditor does not do in a Type I is sample instances of the control across time. There is no request for "the twelve access reviews performed this year" or "every production change in the period with its approval". That absence is precisely why a Type I report gives limited assurance to a customer: it says the controls exist, not that they have been working.
What a Type II report tests
A Type II report includes everything in a Type I and adds the operating effectiveness of the controls over a defined period. The auditor's question becomes: across these months, did each control operate consistently, as designed, every time it was supposed to?
To answer that, the auditor tests samples. For a daily control, they may select a number of days across the period; for a quarterly control, they will usually examine each quarter; for event driven controls such as onboarding, offboarding or production changes, they pull a population of events and sample from it. Each sampled instance must have evidence showing the control was performed correctly and on time.
Operating effectiveness over a period
Operating effectiveness is where programmes that look complete on paper start to show cracks. A well designed offboarding control fails in a Type II if one leaver kept access to a production system for three weeks. A change management control fails if a change reached production without the documented approval. The auditor does not grade intentions; they grade the record.
This is why a Type II is far more persuasive to a customer. It shows that the organisation did not only write good controls but ran them, month after month, under normal operating pressure. For a buyer trying to assess whether a vendor will keep their data safe, that history matters more than any document.
How the observation period is chosen
The length of the observation period is agreed with the auditor; three to twelve months is common. A first Type II often uses a shorter period so the organisation can deliver a report to customers sooner; later reports typically cover twelve months and follow on from each other so there is no uncovered gap.
Customers may have their own expectations. Some procurement teams accept a shorter first period; others specifically ask for six or twelve months. Before choosing a period, it is worth asking the customers who triggered the request what they will accept, so the report answers their question the first time.
Sampling and exceptions
When a sampled instance fails, the auditor records an exception. One exception does not automatically sink a report. The auditor considers how many exceptions occurred, whether they were isolated or systemic, and whether other controls compensated. The exceptions and the organisation's response to them are described in the report, and customers do read that section.
Too many exceptions, or a single serious one, can lead to a qualified opinion on the affected criteria. That is visible to every customer who reads the report. The practical lesson is that the evidence for a Type II is built day by day during the period, not assembled at the end.
Why customers usually ask for Type II
When an enterprise customer's security team sends a questionnaire or asks for "your SOC 2", they are trying to decide whether to trust a vendor with their data. A Type II report gives them independent evidence that controls worked over time. A Type I gives them evidence that controls exist. For most enterprise reviews, the first is what they need.
There is a reason the request often arrives without specifying the type: the person sending it may be in procurement, not security, and may simply be working through a checklist. The security reviewer behind them usually knows the difference.
What procurement and security questionnaires look for
Security reviewers reading a SOC 2 report typically check five things: the report type, the period covered and how recent it is, which Trust Services Criteria are in scope, whether the opinion is unqualified, and which exceptions were noted. They also check complementary user entity controls, the controls the customer itself is expected to operate, and how subservice organisations such as cloud providers are treated.
They may also ask for a bridge letter (sometimes called a gap letter). This is a letter from the organisation's management covering the time between the end of the last report period and today, stating that there have been no material changes to the control environment. It is a representation by management, not an audit document: the auditor performs no work over that gap. Customers generally accept it for short gaps, often up to around three months.
What happens when you bring the wrong report
The most common failure is bringing a Type I to a review that expected a Type II. The deal does not necessarily die, but it usually slows down. The security reviewer may ask for a committed date for the Type II, send a longer questionnaire to compensate, or require contractual commitments in the meantime.
The second failure is bringing a report whose scope does not cover what the customer buys. If the product the customer is purchasing runs on infrastructure or a team outside the report's system description, the report does not answer their question, whatever its type. Checking scope against the customer's use case before the examination starts avoids this.
What has to keep running during the observation period
During a Type II period, every in scope control has to run on schedule and leave evidence. That sounds obvious, but it is where most programmes struggle, because controls depend on people with other jobs. The areas below generate a large share of the samples an auditor will request.
Access reviews and joiners/leavers
Access reviews must happen at the stated frequency, cover every in scope system, and record decisions: who reviewed, what was removed, when. A missed quarter is an exception that cannot be fixed afterwards, because the auditor tests whether it happened at the time.
Joiners and leavers are event driven. For every new starter, there should be an approved access request matching their role; for every leaver, access should be removed within the time the control specifies, across all systems including SaaS tools that sit outside central identity management. Leavers whose accounts were forgotten in one tool are among the most common sources of exceptions.
Monitoring, incidents and change management
Monitoring controls must show that alerts were generated, reviewed and handled. If the control says security alerts are triaged, the auditor will sample alerts and look for evidence of triage and outcome. If incidents occurred, the incident response process must show detection, classification, handling, communication and lessons learned as described.
Change management produces some of the largest samples. Every change to production in scope should show the request, review, approval, testing and deployment as the control describes. Emergency changes need their own documented path. A team that occasionally pushes directly to production without the approval step will generate exceptions quickly.
Vendor reviews
Most service organisations depend on subservice organisations: cloud hosting, payment processors, identity providers. SOC 2 expects the organisation to assess those vendors and monitor them over time, often by collecting and reviewing their own SOC 2 reports. If the control says vendors are reviewed annually, the auditor will check that the reviews happened and that findings were followed up.
The report will also state whether subservice organisations are handled with the carve out method, where their controls are excluded and the customer is pointed to the vendor's own report, or the inclusive method, where their controls are covered within the report. Under the carve out method, the report also lists the controls the organisation assumes the vendor operates, known as complementary subservice organisation controls. Most organisations relying on large cloud providers use the carve out method.
Moving from Type I to Type II
The common path is to complete a readiness assessment, close the gaps, obtain a Type I to confirm design, then open the observation period for the first Type II. Some organisations skip the Type I and go straight to a Type II with a shorter first period. Neither route is wrong; the choice depends on whether customers need something in hand sooner and how confident the organisation is in its control design.
What matters most is what happens between the two. Once the observation period starts, the work changes from building controls to running them. Evidence must be collected continuously, exceptions must be caught and corrected while there is still time, and control owners need someone keeping track of what is due. Qalea's platform maps SOC 2 controls and collects evidence continuously across the period, while Qalea's team provides guided support and operated security, including SOC monitoring, vulnerability management and vCISO oversight, so the controls the report describes are the controls actually running. The CPA firm remains the independent party that issues the report.
How SOC 2 relates to ISO 27001
SOC 2 and ISO 27001 cover much of the same ground, which is why companies selling to both US and European customers are often asked for both. The difference is in form. ISO 27001 is a certifiable standard: an accredited certification body audits the management system and issues a certificate, followed by surveillance audits. SOC 2 is an attestation: a CPA firm examines controls and issues an opinion in a report.
In practice, a large share of controls and evidence can serve both. Access management, change management, incident response, vendor management and risk assessment appear in both frameworks. The ISO 27001, SOC 2 and TISAX overlap post maps where they meet and where they diverge, and what a certification audit actually tests explains how auditors approach evidence in each. Running both from one set of controls, rather than two parallel programmes, is what keeps the second framework from doubling the work. The rest of the series is on the SOC 2 topic page.
