A SOC 2 report is the document every SaaS vendor sends when a customer asks whether it is secure, and it is read, when it is read at all, by scanning for the word “exception.” The report may cover a system that is not the one you use, a period that ended five months ago, and two of the five categories that matter to you; it may carve out the cloud provider that holds all of your data; its description may disclose, in a paragraph on page thirty-one, a security incident during the period; and its complementary user entity controls may assume that you have done six things you have not done. None of this is concealed. It is in the report, in sections that were written for exactly the reader who skipped them to look for the exceptions.
This guide is the user entity’s method for a SOC 2 report: what the report is under the AICPA’s Trust Services Criteria and what it is not, which categories should be in scope for the way you use the service, the anatomy of the report and the scope-gerrymandering red flags, a ten-question review that ends in a reliance conclusion and a vendor-management action list, how to evaluate the service auditor’s exceptions for your purposes, how to map and operate the complementary user entity controls, a review memo template, and a worked example at Lakeshore Bancorp, whose review of its digital banking platform provider’s report found a four-month gap, three exceptions and two disclosed incidents that nobody at the bank had read. It mirrors the SOC 1 review method, which covers the financial-reporting report, and the two are designed to be used together: most critical vendors issue both, and most user entities need both.
In this guide
- What a SOC 2 report is, and what it is not
- Which categories belong in scope for the way you use the service
- The anatomy of the report, and the scope red flags
- Reading the tests: how much assurance is actually there
- The ten-question review
- Evaluating the service auditor’s exceptions for your purposes
- Complementary user entity controls: the controls the report assumes you operate
- Incidents, changes and the bridge letter
- Where the review sits in vendor management: tiers and cadence
- The SOC 2 review memo template
- Worked example: Lakeshore Bancorp reviews its digital banking provider’s report
- Common mistakes
What a SOC 2 report is, and what it is not
A SOC 2 report is the product of an examination engagement performed by a service auditor under AT-C section 205 of the AICPA’s attestation standards, in which the auditor opines on management’s description of the service organization’s system and on the suitability of design and, in a Type 2 report, the operating effectiveness of controls, measured against the Trust Services Criteria. The current criteria are the 2017 Trust Services Criteria with the revised points of focus issued in 2022. They are organized in five categories: security, availability, processing integrity, confidentiality and privacy. Security is the mandatory category and is expressed as the common criteria, CC1 through CC9, built on the COSO 2013 principles for the first five (control environment, communication and information, risk assessment, monitoring, control activities) and adding four series specific to systems: CC6 logical and physical access, CC7 system operations, CC8 change management and CC9 risk mitigation. The other four categories are optional and add their own criteria series, A1 for availability, PI1 for processing integrity, C1 for confidentiality and P1 through P8 for privacy. Each criterion carries points of focus, which are illustrative considerations rather than requirements; a service organization need not address every point of focus, which is why two clean reports can describe very different control environments.
What the report is not is a financial-reporting document. A SOC 2 report says nothing about the control objectives that matter to your financial statements; that is the SOC 1 report’s territory under AT-C 320, and a vendor that offers a SOC 2 in place of a SOC 1 for a payroll or transaction-processing service has offered the wrong document. It is also not a certification. An ISO/IEC 27001 certificate states that an information security management system conforms to the standard; a SOC 2 report describes specific controls and, in Type 2 form, reports the results of testing them over a period, which is a different and for most purposes more useful thing. And it is not general-use: a SOC 3 report is the general-use summary with no test detail, and a vendor that offers only a SOC 3 has offered marketing.
| Document | Standard and criteria | What it tells you | What it does not |
|---|---|---|---|
| SOC 2 Type 1 | AT-C 205; Trust Services Criteria | Description is fair and controls are suitably designed as of a date | Whether anything operated |
| SOC 2 Type 2 | AT-C 205; Trust Services Criteria | Design and operating effectiveness over a period, with tests and results per criterion | Anything outside the described system, categories and period |
| SOC 1 Type 2 | AT-C 320; the service organization’s own control objectives for financial reporting | Controls relevant to user entities’ financial statements over a period | Security, availability or privacy beyond what affects financial reporting |
| SOC 3 | Trust Services Criteria; general-use | Summary opinion | Tests, results, exceptions, CUECs |
| ISO/IEC 27001 certificate | ISO/IEC 27001:2022; certification body audit | An ISMS conforms to the standard; scope statement | Which controls, how tested, with what results; the Statement of Applicability is not usually shared |
| Vendor security questionnaire | None | What the vendor says about itself | Anything independently verified |
Which categories belong in scope for the way you use the service
Because only security is mandatory, the first question a reviewer asks is not “is the opinion clean” but “does this report cover the categories my use of the service requires.” A vendor chooses its categories, and a report covering security alone from a vendor that hosts your production application and processes your transactions has been scoped to what the vendor could pass rather than to what you rely on. The table maps common uses of a service to the categories a reviewer should expect and the gap if a category is missing. The mapping is done once per vendor, recorded in the review memo, and compared with the report’s cover page before anything else is read.
| What the vendor does for you | Categories to expect | Why | If absent |
|---|---|---|---|
| Hosts an application your operations depend on | Security and availability | Availability criteria (A1) cover capacity, recovery and backup for the commitments the vendor makes | Availability commitments are untested; ask for A1 in the next report or test the vendor’s continuity evidence directly |
| Processes transactions whose accuracy you rely on (billing, payments, payroll) | Security and processing integrity, plus a SOC 1 where financial reporting depends on it | PI1 criteria cover completeness, accuracy, timeliness and authorization of processing | Processing accuracy rests on your own reconciliation controls only |
| Holds your confidential business data or your customers’ data | Security and confidentiality | C1 covers identification, protection and disposal of confidential information | Retention and disposal of your data are unassured |
| Processes personal data on your behalf | Security and privacy, or security plus contractual privacy obligations and your own privacy audit | P1 to P8 cover notice, choice, collection, use, retention, access, disclosure and quality | Rely on the data processing agreement and your privacy program controls instead |
| Provides infrastructure other vendors build on | Security, availability, confidentiality; usually all five from the major providers | Subservice organization for your vendors’ reports | Follow the chain from your vendor’s carve-out |
The anatomy of the report, and the scope red flags
A SOC 2 report has the same five sections as a SOC 1: the service auditor’s report, management’s assertion, management’s description of the system, the tests of controls and results, and other information not covered by the opinion. The description is written to the AICPA’s description criteria and must state the system’s boundaries, the services provided, the principal service commitments and system requirements, the relevant aspects of infrastructure, software, people, procedures and data, the complementary user entity controls, the subservice organizations and the method used for them, and any significant changes and, under the description criteria, incidents during the period that were the result of controls failing. The reading order is the same as for SOC 1: opinion for scope and modifications, description for boundaries, commitments, CUECs, subservice organizations and incidents, then every line of tests and results, then the other information. The SOC 1 guide gives the section-by-section table; the SOC 2 additions are the categories on the cover, the principal service commitments in the description, which are the vendor’s own promises of availability and security and should match the ones in your contract, and the incident disclosure.
Scope gerrymandering is the SOC 2 reviewer’s particular problem, because the vendor defines the system. The red flags are specific. A system description that names a product, region or data center other than the one you use, or that excludes the module you depend on. A report period of three or six months for a vendor that has been in business for years, which usually means a recent failure or a recent start. A change of service auditor without explanation, especially to a firm the reviewer has not heard of, or a report signed by a firm whose only business is issuing SOC reports quickly. A report with several hundred controls and no exceptions, which is possible and rare. Controls under CC6, CC7 and CC8 tested by inquiry and inspection of a policy rather than by sampling the population. A carve-out of the hosting provider with no complementary subservice organization controls stated, or CSOCs stated so broadly that everything material sits at the subservice organization. And a description that is silent on incidents in a year when the vendor’s own status page or the trade press reported an outage or a breach. Each is a question for the vendor, not a conclusion, and the answers go in the memo.
Reading the tests: how much assurance is actually there
Two SOC 2 reports with unmodified opinions can carry very different amounts of assurance, and the difference is in section four. The service auditor chooses the nature and extent of testing, and the report states, for each control, what was done: inquiry of personnel, observation of a process, inspection of documents or configurations, or re-performance of the control. Inquiry alone proves that someone said the control operates. Inspection of a policy proves the policy exists. Sampled inspection of the control’s evidence over the period, twenty-five terminations traced to removal timestamps, forty changes traced to approvals, is the level at which reliance becomes reasonable, and re-performance is stronger still. The reviewer reads the testing column for every control under the criteria in scope and records how many key controls, particularly under CC6, CC7 and CC8, were tested by inquiry or policy inspection only; a report in which the access and change controls were tested that way supports much less than its opinion suggests. The table gives the reading.
| Test type stated in the report | What it establishes | Reliance it supports | What to look for |
|---|---|---|---|
| Inquiry | Personnel described the control | Understanding only | Key controls tested by inquiry alone are effectively untested |
| Observation | The control was seen operating once | Design and implementation at a point in time | Useful for physical and process controls; weak for periodic controls |
| Inspection of policies and configurations | The rule exists or the setting is in place at the date inspected | Design; operation only with change-control reliance, as for any automated control | Configuration inspections should be paired with change-history evidence |
| Inspection of a sample of evidence over the period | The control operated on the sampled occasions | Operating effectiveness for the period, proportionate to sample size and population | Sample sizes stated; populations described; exceptions counted against the sample |
| Re-performance | The auditor independently executed the control | Strongest evidence of operation | Rare in SOC 2 reports; valued where present |
Thinness has a second form: one control per criterion. The criteria are broad, and a vendor that maps a single control to CC7.1 (vulnerability identification and monitoring) has met the letter of the framework with less than most customers would expect. The reviewer compares the controls listed under each relevant criterion with what a competent vendor of that type would be expected to have, using the points of focus as a checklist of what could be there, and asks the vendor about the gaps. Points of focus are not requirements, but a vendor whose report addresses two of nine points of focus under a criterion you care about has told you something about its program.
The ten-question review
The review is ten questions answered in order with evidence, ending in a conclusion about reliance and a list of vendor-management actions. It takes two to four hours for a typical report and is repeated when each new report arrives. The questions parallel the SOC 1 review with three substitutions: categories replace control objectives, principal service commitments replace financial assertions, and the conclusion feeds vendor management and the security function rather than the financial reporting reliance decision. The table gives the questions, where the answers are, and the action if an answer is wrong.
| # | Question | Where the answer is | If the answer is wrong |
|---|---|---|---|
| 1 | Is this the right report: the entity we contract with, the system and product we use, the regions and data centers that hold our data? | Opinion; description boundaries | Obtain the correct report; treat the service as unassured meanwhile |
| 2 | Is it Type 2, and does the period cover enough of the last twelve months, with continuity from the prior report? | Cover; opinion; prior report | Type 1: design only. Gap over three months: bridge letter plus inquiry; longer: additional procedures |
| 3 | Do the categories match the way we use the service? | Cover; category mapping in the memo | Missing category: record the gap, request inclusion, test directly where critical |
| 4 | Is the opinion unmodified, and what do the emphasis and other-matter paragraphs say? | Opinion | Qualified or adverse: identify affected criteria; escalate to vendor management |
| 5 | Do the principal service commitments match our contract, and were they met? | Description; contract; A1 and CC results; incident disclosures | Commitments weaker than the contract or unmet: contractual action |
| 6 | What was tested under the criteria we care about, how, with what samples, and what were the results? | Tests and results, line by line for CC6, CC7, CC8 and the optional categories in scope | Inquiry-only testing of key controls: reduced reliance; exceptions under question 7 |
| 7 | What does each exception mean for our data and our service? | Exceptions; management responses; our own compensating controls | Unmitigated exceptions affecting our data: vendor action plan with dates; heightened monitoring |
| 8 | Which complementary user entity controls are we expected to operate, and do we, with evidence? | Description CUEC list; our control inventory | Unoperated CUECs are our gaps; assign and remediate |
| 9 | Which subservice organizations are carved out, what do they hold, and what assurance covers them? | Opinion; description; CSOCs | Obtain the subservice report; accept and record any residual gap |
| 10 | What incidents and changes were disclosed, what changed after the period, and what is our conclusion and action list? | Description incidents and changes; bridge letter; the memo | Conclusion recorded as reliance, limited reliance or none; actions assigned in vendor management |
Evaluating the service auditor’s exceptions for your purposes
An exception in a SOC 2 report is evaluated the same way as in a SOC 1: relevance to the categories and criteria you rely on, whether your data or your service instance was affected, whether a control on your side compensates, and the exposure if nothing did. The difference is what the exposure is. In a SOC 1 it is a misstatement; in a SOC 2 it is a breach of your data, an outage of your service or a processing error, and the compensating controls are your own security and continuity controls rather than your financial reviews. The deficiency evaluation framework still supplies the structure; the table shows the evaluation for exceptions that recur in SOC 2 reports, each of which appears in the worked example below.
| Exception as reported | Criteria | What it means for us | Compensating control on our side | Action |
|---|---|---|---|---|
| For 2 of 25 terminated employees, logical access was removed more than five business days after termination | CC6.2, CC6.3 | Former vendor staff retained access to the platform that holds our data | None; our data is in their environment | Ask whether the accounts accessed our tenant; confirm remediation; monitor next report |
| For 6 of 40 high-severity vulnerabilities, remediation exceeded the vendor’s 30-day standard | CC7.1 | Exploitable weaknesses in the platform for longer than promised | Our own network controls if the platform is not internet-facing; otherwise none | Obtain the vendor’s current vulnerability aging; contractual remediation SLA if absent |
| For 3 of 45 changes, evidence of approval prior to deployment was not retained | CC8.1 | Changes to the platform we use may have been unauthorized | Our regression testing of our configuration after releases | Confirm our release-review control operated; note for change-management reliance |
| Backup restoration was not tested during the period | A1.2, A1.3 | Recoverability of our data is unproven | Our own export or backup of tenant data | Test our export; require a restore test in the next period; see the backup guide |
| Multi-factor authentication was not enforced for 4 of 30 sampled administrative accounts | CC6.1 | Vendor administrators with access to our data protected by password only | None | Escalate; obtain remediation date; consider heightened logging of vendor access to our tenant |
Complementary user entity controls: the controls the report assumes you operate
SOC 2 reports list complementary user entity controls just as SOC 1 reports do, and the SOC 2 versions are usually about identity, configuration and data handling: the customer is responsible for managing its own users and their access, for enforcing multi-factor authentication for its users, for configuring the product’s security settings, for classifying and protecting the data it uploads, for managing encryption keys it holds, for reviewing the notifications and logs the vendor provides, and for its own network and endpoint security. Each is mapped to a control the customer operates, an owner and evidence, and each unoperated one is the customer’s gap. The mapping is frequently revealing because SaaS products ship with permissive defaults and the CUEC list is, in effect, the vendor telling you which defaults to change. The identity and access management guide covers the user-management side and the cloud audit guide the configuration side; the mapping table format is the one in the SOC 1 guide.
Incidents, changes and the bridge letter
Three things in a SOC 2 report describe what happened rather than what was designed. The description criteria require the description to disclose incidents during the period that resulted from controls not operating effectively and that were significant enough to affect the service commitments; a description that discloses two security incidents is not a red flag, it is a vendor being candid, and the reviewer’s question is what the vendor changed. Significant changes to the system during the period are disclosed in the description and matter because the tests may have been performed on the system before or after the change. And the period gap between the report’s end date and the review date is covered, for up to about three months, by a bridge letter from the vendor’s management stating whether material changes have occurred; it is a representation, not assurance, and beyond a few months it is not enough. The incident response audit covers the customer’s side of provider incidents: the contract clauses that oblige the vendor to notify you and the intake path that gets the notification to your incident process.
Where the review sits in vendor management: tiers and cadence
The SOC 2 review is one control in a third-party management program, and its depth should follow the vendor’s tier. A critical vendor, one that hosts a core system, holds regulated or confidential data at scale, or whose failure would stop a business process, warrants the full ten-question review annually, a bridge letter for any gap, a review of the vendor’s penetration test summary and security questionnaire, contract clauses for notification and audit rights, and an exit plan. A material vendor warrants the review with less CUEC testing and a lighter questionnaire. A low-tier vendor holding no sensitive data may need only confirmation that a current report exists and the opinion is unmodified. The tiering is set in the third-party inventory that the IT audit plan is built on and that the Third-Party Topical Requirement expects an engagement to assess, and the cadence is driven by the report’s delivery date rather than by the calendar year: the review is due when the report arrives, the bridge letter is requested when the gap exceeds a quarter, and the next report’s due date is recorded in the memo so that its absence is noticed. An organization with two hundred SaaS vendors cannot review two hundred reports to this depth and should not try; it reviews the twenty that matter properly and confirms the rest exist, which is a defensible position only if the tiering was done.
The SOC 2 review memo template
The memo is completed for every SOC 2 report relied on, filed with the report and the bridge letter in the vendor record, and updated when the next report arrives. It follows the ten questions and carries two attachments, the category-and-criteria mapping and the CUEC mapping. The Third-Party Topical Requirement guide covers where the memo sits in a third-party management engagement, and the templates directory lists the companions.
SOC 2 report review memo. Vendor: ________ Service and system: ________ Report type, categories and period: ________ Service auditor: ________ Reviewed by: ________ Date: ________ Approved by: ________ Date: ________
1. Reliance context. [What the vendor does for us; data held; criticality tier; contractual commitments (availability, security, notification); categories required per our use (Attachment A).]
2. Report identification (question 1). [Entity, system, product, regions and data centers compared with our contract and configuration.]
3. Type, period and continuity (question 2). [Type 2 confirmed; period ________ to ________; gap to today ________; bridge letter dated ________; prior report period ________.]
4. Categories (question 3). [Categories in the report versus categories required; gaps and actions.]
5. Opinion (question 4). [Unmodified / qualified / adverse; emphasis paragraphs.]
6. Service commitments (question 5). [Principal service commitments versus contract; evidence they were met; incidents disclosed.]
7. Tests and results (question 6). [For CC6, CC7, CC8 and the optional categories in scope: testing nature, samples, results; inquiry-only controls listed.]
8. Exception evaluation (question 7). [Each exception: criteria, relevance, effect on our data or service, compensating control, action and owner.]
9. Complementary user entity controls (question 8). [Attachment B mapping; unoperated CUECs and remediation.]
10. Subservice organizations (question 9). [Carve-outs, what they hold, reports obtained, CSOC mapping, residual gaps.]
11. Incidents, changes and post-period events (question 10). [Disclosed incidents and the vendor’s response; significant changes; bridge letter content; our own knowledge.]
12. Conclusion and actions. [Reliance / limited reliance / none; vendor-management actions with owners and dates; contractual actions; next report due date and owner.]
Worked example: Lakeshore Bancorp reviews its digital banking provider’s report
Lakeshore Bancorp, the nine-billion-dollar public regional bank with twenty-two internal auditors that appears in several of this site’s IT guides, runs its online and mobile banking on a platform operated by a specialist vendor that hosts the application on a major cloud provider. The vendor issues a SOC 2 Type 2 report covering security, availability and confidentiality for the twelve months to 30 June, and a separate SOC 1 report for the transaction-processing controls. The bank’s vendor management function had recorded the SOC 2 as received each year. Internal audit reviewed it in the FY26 third-party management engagement, using the ten questions, and the review took a senior auditor a day plus a further day of CUEC testing with the digital banking product owner.
Questions 1 to 4 produced one issue: the report was the right one, Type 2, unmodified, with the three categories the bank’s use required, but the review was performed in November, four months after the period end, and no bridge letter had been requested; one arrived in a week and disclosed a data-center migration completed in September. Question 5 compared the vendor’s principal service commitments with the contract and found the report committed to 99.9 percent availability while the contract required 99.95, a difference the bank’s vendor manager had not noticed in three years. Question 6 read the 187 tests under the criteria in scope and found three exceptions, all in the table above: two of twenty-five terminated vendor employees with access removed late, six of forty high-severity vulnerabilities remediated beyond thirty days, and no backup restoration test in the period. Question 7 evaluated them: the late removals could not be tied to the bank’s tenant from the report and the vendor was asked whether the accounts had accessed it (they had not); the vulnerability aging was escalated with a request for current metrics; and the missing restore test was treated as a real gap because the bank had never tested its own export of customer transaction data.
Question 8 was the bank’s own finding. The report listed nine complementary user entity controls; the bank operated seven. It had not enforced multi-factor authentication for its own administrative users of the vendor’s console, and it had never reviewed the security notifications the vendor delivered to a shared mailbox, in which the two disclosed incidents of the period, a credential-stuffing wave and a denial-of-service event, had been reported at the time. Question 9 followed the carve-out to the cloud provider, whose report was obtained and mapped. Question 10 recorded the two incidents, the migration, the bridge letter, and a conclusion of limited reliance pending the vendor’s vulnerability metrics, with five actions.
| Question | Result | Action and owner |
|---|---|---|
| 1 to 4 | Correct report; Type 2; security, availability, confidentiality; unmodified; four-month gap with no bridge letter | Bridge letter obtained (migration disclosed); review calendar set to report delivery (vendor management) |
| 5 Commitments | Report commits to 99.9 percent availability; contract requires 99.95 | Contract and commitment reconciled; SLA credits reviewed (vendor management, legal) |
| 6 and 7 Exceptions | Late access removals (not affecting the bank’s tenant); vulnerability aging; no restore test | Vulnerability metrics requested quarterly; bank’s own export restore tested (product owner, security) |
| 8 CUECs | 7 of 9 operated; console MFA not enforced; vendor notifications unread | MFA enforced within two weeks; notification mailbox routed into the incident intake (security) |
| 9 Subservice | Cloud provider carved out; report obtained and mapped | CSOC mapping filed |
| 10 Incidents and changes | Two incidents disclosed and unread by the bank; data-center migration after period end | Incidents assessed for customer impact; migration covered by inquiry until next report |
| Conclusion | Limited reliance pending vulnerability metrics; CUEC gaps are the bank’s findings | Two findings raised (Medium, Low); memo approved by the CAE |
The CAE’s note to the audit committee made the point that the report had contained, for three years, a disclosed availability commitment weaker than the contract and two security incidents affecting the bank’s customers, and that the bank’s control had been to file it. The vendor management procedure was changed so that the ten-question memo is the record of receipt, and the incident response intake now includes the vendor notification channel.
Common mistakes
- Accepting security-only when you rely on availability or processing. Map your use to categories before reading, and record the gap.
- Reading the opinion and stopping. The system boundary, the commitments, the CUECs, the incidents and the exceptions are all in the description and the tests.
- Missing scope gerrymandering. Check the system, region, period, auditor, testing method and carve-outs against the red flags.
- Not comparing commitments to the contract. The vendor’s promise in the report and its promise in your contract are often different numbers.
- Ignoring the CUECs. They are the vendor telling you which defaults to change; every unoperated one is your gap.
- Treating a SOC 2 as a SOC 1. Financial reporting reliance needs the SOC 1 under AT-C 320.
- Treating an ISO certificate as equivalent. Conformance of a management system is not a tested control report.
- Skipping the incident disclosures. They are the most candid paragraph in the report and the one to ask the vendor about.
- Filing the notifications. Route vendor security notifications into your incident intake.
- Reviewing once. Reports are annual; the memo, the bridge letter and the CUEC testing recur.
Related guides
- How to review a SOC 1 report
- The Third-Party Topical Requirement
- Auditing cloud computing
- How to audit incident response
- How to audit backups and recovery
- How to audit identity and access management
- How to audit IT change management
- Control deficiency evaluation
- SOX ITGC scoping
- Building the IT audit plan
- Auditing cybersecurity programs
- Templates and downloads
Leave a Reply