# How to Read a SOC 2 Report for Legal AI

> A vendor says it is SOC 2 certified. Here is how a law firm reads the report: Type I vs Type II, scope, the auditor opinion, and the exceptions nobody opens.

[Home](https://rankshieldlegal.com/) / [Blog](https://rankshieldlegal.com/blog/) / Firm Security Vendor verification
# How to Read a SOC 2 Report for a Legal AI Tool
A SOC 2 report is a signal, not a guarantee that your client data is safe. To read one for a legal AI tool, check five things in order: whether it is Type I or Type II, which Trust Services Criteria are in scope, what the system description actually covers, whether the auditor gave an unqualified opinion, and above all the exceptions section that lists the control failures the auditor found and that most buyers never open.

By [Jamie Kloncz](https://rankshieldlegal.com/about/), Founder, RankShield ** 20 min read ** Published July 13, 2026

To read a SOC 2 report for a legal AI tool, work through five parts in order: confirm whether it is Type I or Type II, read which Trust Services Criteria are in scope, study the system description to see whether the AI feature you care about is actually covered, find the independent auditor's opinion and whether it is unqualified or qualified, and then read the tests of controls and the exceptions the auditor recorded. A SOC 2 is a report produced by an independent CPA firm against the AICPA's Trust Services Criteria [[1]](#ref-1). It is meaningful evidence that specified controls were examined for a stated scope and period. It is not proof that your specific matter is safe, and it never claims to be.
Most vendors describe themselves as "SOC 2 certified" and expect the phrase to end the conversation. Most buyers accept it, because the report is long, technical, and shared under NDA, so it rarely gets opened. That is the gap this guide closes. A law firm does not need to be an auditor to read a SOC 2 report usefully. It needs to know which five parts carry the weight, what each one can and cannot tell you, and where a certification stops answering the question that privilege actually turns on: where does the client's data go, and can you show it. This piece is written for a lawyer or firm committee, not for a security team, and it pairs with our companion guide on the [security questionnaire that vets a legal AI vendor](https://rankshieldlegal.com/vet-legal-ai-vendor-security-questionnaire/).

## What a SOC 2 report is, and what "certified" leaves out
A SOC 2 is an assurance report produced by an independent CPA firm that examines a service organization's controls against the AICPA's Trust Services Criteria [[1]](#ref-1). The word "certified" is doing more work in marketing than it does in the report itself. There is no pass or fail stamp on the cover. What you receive is an auditor's written opinion, a description of the system the vendor provided, the criteria the auditor tested against, and the results of that testing, including anything the auditor found wanting. The value is in the detail, not in the fact that a report exists.
This matters for legal AI specifically because the phrase "we are SOC 2 certified" says nothing about the part of the product you most need to understand. A report can be entirely genuine and still tell you almost nothing about how a client's uploaded deposition is processed, whether the prompt is logged, or which model host receives it. The certification confirms that a security program was examined. It does not narrate the data flow, and the data flow is where confidentiality risk lives. Treat the report as a starting document that you read, not a badge that closes the file.
One practical habit sets careful readers apart from the rest: ask for the full report, not a summary, a logo, or a screenshot of the cover page. The parts that matter, the scope, the opinion, and the exceptions, are all inside the document. A vendor comfortable with its own controls will share the report under an NDA. A vendor that offers only the badge is answering a different question than the one you asked.
A SOC 2 report is not a certificate you either have or lack. It is an auditor's opinion plus evidence. The useful information is in the pages most people never open, not on the cover.

## Type I and Type II report the same controls but very different evidence
Type I says the controls were designed on a given day. Type II says they were tested and observed operating across a period. When client data is involved, ask for Type II and read the observation period.
The first thing to check on any SOC 2 report is which type it is, because the two types answer different questions. A Type I report is a point-in-time assessment: it evaluates whether the vendor's controls are suitably designed as of a single date. A Type II report evaluates whether those same controls actually operated effectively over a period of time, commonly three to twelve months [[1]](#ref-1) [[2]](#ref-2). Design is a promise on paper. Operation over a period is evidence of behavior. For a tool that will handle privileged material, Type II is the stronger evidence, and a vendor that offers only a Type I is telling you the controls were drawn up but not yet observed in practice over time.
This does not make a Type I worthless. A young vendor may legitimately have only a Type I while its first Type II observation period runs, and that can be an acceptable interim position for a low-risk pilot. What it means is that you should read the type, not assume it. When a sales deck says "SOC 2" without a numeral, ask which one, and ask for the observation period if it is a Type II. The table below sets out the difference in plain terms.
Question SOC 2 Type I SOC 2 Type II
What it assesses Whether controls are suitably designed Whether controls operated effectively
Time frame A single point in time A period, commonly 3 to 12 months
Evidence strength Design on paper Observed behavior over time
What to ask for The as-of date The full observation period and its end date
Best used for An interim or early-stage view Relying on a tool for sensitive matters

Source: AICPA & CIMA; Linford & Company (2026) Download SVG

## The five Trust Services Criteria and which ones a legal buyer should expect
SOC 2 is built on the AICPA's Trust Services Criteria, and there are five of them: Security, Availability, Processing Integrity, Confidentiality, and Privacy [[1]](#ref-1) [[2]](#ref-2). Only Security is required in every SOC 2 report. The other four are optional, and the vendor chooses which to include based on the services it provides. This is the detail that trips up buyers who assume a SOC 2 automatically covers everything the name might imply. It does not. A report can be a legitimate SOC 2 while covering only the Security criterion.
For a legal AI tool, the criteria you would hope to see are Security plus Confidentiality, and Privacy where the tool handles personal data. Confidentiality speaks to how information designated as confidential is protected, which maps closely to a firm's concerns. Its absence is not a disqualifier by itself, but it is a question worth asking: if a vendor markets to law firms and its SOC 2 covers Security alone, find out why Confidentiality was left out of scope. The point is not to demand all five criteria. It is to read which criteria the auditor actually tested against, and to notice when the ones most relevant to your duty are missing.

- Security: the only criterion required in every SOC 2 report; covers protection against unauthorized access.
- Availability: whether the system is available for operation as committed; relevant to uptime, less to confidentiality.
- Processing Integrity: whether processing is complete, valid, accurate, and authorized.
- Confidentiality: how information designated confidential is protected; the criterion most aligned with a firm's duty.
- Privacy: how personal information is collected, used, retained, and disclosed; relevant when the tool handles personal data.

## The scope and system description decide whether the AI feature is even covered
Every SOC 2 report contains a description of the system, written by the vendor and examined by the auditor. This section defines the boundary of the audit: which product, which environment, and which time period the report covers. It is the most important section for a legal buyer to read carefully, and it is routinely skimmed. The reason it matters is that a vendor's SOC 2 boundary and the AI feature you care about are not always the same thing. A company can hold a genuine SOC 2 covering its corporate systems, its customer portal, and its billing stack while the inference pipeline, the model host, and the prompt-logging path sit outside the audited boundary.
When that happens, the badge looks identical, but it is answering a different question than the one you need answered. So read the system description and locate the specific product and components you will actually use. If your firm will upload documents to an AI drafting feature, confirm that the drafting feature and its data path are named in the description, not just the parent platform. Watch for carve-outs, where certain sub-service organizations or components are explicitly excluded, and for language that scopes the report to a service tier your firm is not on. If the AI pipeline is not clearly inside the boundary, the report does not cover the thing you are evaluating, however impressive it looks.
A short test helps here. Read the system description and try to trace, in your own words, the path a client document takes from upload to storage to deletion, using only what the report states. If you cannot follow that path inside the described boundary, the scope is either too narrow or too vague to rely on for privileged material, and that is a specific, answerable question to put back to the vendor.
The system description is where the audit's boundary is drawn. An AI feature outside that boundary is not covered, no matter how strong the report is for everything inside it.

## The auditor's opinion is the sentence most buyers skip
An unqualified opinion is the auditor's clean conclusion. A qualified one flags reservations. Either way, read the opinion in the auditor's own words before you rely on anything else in the report.
Near the front of the report sits the independent service auditor's opinion, a short letter that states the auditor's overall conclusion. This is the sentence to find first among the parts you read, because it colors everything else. The best outcome is an unqualified opinion, meaning the auditor concluded the controls were suitably designed and, for a Type II, operated effectively across the period, without material reservation. A qualified opinion means the auditor found one or more issues significant enough to note as an exception to that conclusion. A qualified opinion is not automatically fatal, but it is a signal to read the specifics closely and understand exactly what the auditor could not attest to.
Do not stop at seeing that an opinion exists. Read whether it is unqualified or qualified, and read the auditor's own language about the scope of their work. The opinion is the auditor speaking in their own voice, distinct from the vendor's system description, which is the vendor speaking. When the two are read together, the opinion tells you how much weight the auditor was willing to put behind the description. If the opinion is qualified, the reasons will point you directly to the parts of the report that need the hardest reading.

## The tests of controls and the exceptions section almost nobody reads
The longest part of a Type II report is a detailed section, usually a large table, that lists each control, describes the test the auditor performed, and records the result. This is where the report stops being a summary and becomes evidence. For most controls the result will read as no exceptions noted. But scattered through this section you may find exceptions, also called deviations: specific instances where the auditor tested a control and found it did not operate as intended during the period. An access review that was not completed on time, a change that went to production without the required approval, a former employee whose access was not promptly removed. These are the findings that matter most, and they are the ones almost nobody opens the report to read.
Read the exceptions, and read the vendor's management response that usually accompanies each one. An exception is not automatically disqualifying. Auditors are documenting a real program, and real programs have imperfections. What you are assessing is the pattern and the seriousness: is the exception in a control that touches data confidentiality or access, or in a peripheral area; was it a one-off or a repeated failure; and does the management response describe a genuine remediation or a deflection. A report with a small number of minor, well-remediated exceptions can be more trustworthy than one with none, because it reads like an honest examination rather than a staged one. The failure mode to avoid is treating the presence of an unqualified opinion as permission to skip this section entirely.

- Find the tests-of-controls table and scan the results column for anything other than "no exceptions noted."
- For each exception, read what control failed, how many instances, and whether it touches access or confidentiality.
- Read the management response to each exception and judge whether it describes real remediation.
- Weigh the pattern, not the count: a few minor, remediated exceptions can signal an honest audit.
- Treat exceptions in access, change management, or data handling as the ones that most deserve follow-up.

## Report recency and the gap between the period and today
A SOC 2 Type II covers a defined observation period that has already ended by the time you read the report. There is always a gap between the end of that period and the moment you are relying on the document, and for a fast-moving AI product that gap can matter. A report whose period ended eighteen months ago describes a system that may have changed its model host, its sub-processors, or its retention defaults several times since. Check the period end date, and check how recent it is. A common expectation is an annual cadence, so a report more than roughly a year past its period end deserves a question about when the next one is due.
This recency gap is not a flaw in SOC 2; it is a structural feature of any point-in-time or period-based audit. It is also the precise limitation that a firm should hold in mind when a vendor presents a report as ongoing proof. The report proves something about a past window. It cannot prove that nothing has changed since, and with generative AI products, things change often. Ask the vendor what has materially changed since the period end, and treat a vague answer the same way you would treat a vague answer to any other diligence question.

## What a SOC 2 proves, and what it does not
It helps to state the boundary of a SOC 2 plainly, because the marketing rarely does. A SOC 2 proves that an independent CPA firm examined specified controls against stated criteria, for a defined scope and period, and reached an opinion, with any exceptions recorded [[1]](#ref-1). That is real and useful. It screens out vendors with no security program to speak of, and it gives you a documented basis for comparison. What it does not do is prove that your specific client data is safe, that the scope covers the exact AI feature you will use, or that nothing has changed since the period closed. It is a strong signal. It is not a guarantee, and it never expires into one.
The table below separates the two columns so they do not get blurred in a sales conversation. Keep it in mind when a vendor offers a SOC 2 as the final word. The right response is not to dismiss the report, which would be its own mistake, but to accept it for exactly what it attests and to keep asking about the parts it does not reach. Our companion piece on [why verifiable evidence beats self-attestation](https://rankshieldlegal.com/why-verifiable/) develops this distinction further.
A SOC 2 report proves A SOC 2 report does not prove
Controls were examined by an independent CPA firm Your specific matter or document is safe today
Testing was done against stated Trust Services Criteria The scope covers the exact AI feature you will use
Results and exceptions for a defined period Nothing has changed since the period ended
A security program exists and was observed How every prompt or upload is actually handled
A documented basis for comparing vendors A per-interaction record you can verify yourself

A SOC 2 is a strong signal that specified controls were tested for a stated scope and period. It is not a promise that your data is safe forever, and it should not be read as one.

## A short procedure for reading a report you receive
Reading a SOC 2 report becomes manageable when you stop trying to read it end to end and instead go straight to the parts that carry the weight. The steps below are the order a legal buyer can follow on any report, without a security background. Each step is a specific question with a specific place to find the answer, and the whole pass can be done in under an hour on a report of normal length. Keep notes as you go, because the answers become part of your vendor file alongside the questionnaire and the contract.
The goal of this procedure is not to turn a lawyer into an auditor. It is to let a firm decide, on evidence rather than on a badge, whether a report supports relying on a tool for a given class of matter. If a step cannot be completed because the report is vague or the relevant section is missing, that is itself a finding, and a precise one you can raise with the vendor.

- **Confirm the type and period** Find whether it is Type I or Type II, and for Type II read the observation period and its end date. Prefer a recent Type II for sensitive matters.
- **Read the criteria in scope** List which of the five Trust Services Criteria the report covers. Expect Security, and look for Confidentiality and, where relevant, Privacy.
- **Trace the system description** Locate the specific AI product and data path you will use, and confirm it sits inside the audited boundary rather than in a carve-out.
- **Read the auditor's opinion** Find the independent auditor's letter and note whether the opinion is unqualified or qualified, in the auditor's own words.
- **Work the exceptions** Scan the tests-of-controls results for exceptions, read each management response, and weigh whether any touch access or confidentiality.
- **Record the gaps** Note anything the report does not cover, and carry those items into your questionnaire, contract, and ongoing monitoring.

## Where a SOC 2 ends and independent verification begins
Reading a SOC 2 well leaves you with an honest picture of its edges. It is periodic, it is scoped to what the vendor chose to include, and it describes a past window rather than the interaction happening right now. Those edges are not defects to complain about; they define the lane a SOC 2 occupies. A different and complementary kind of assurance sits beside it: independent, ongoing verifiability, meaning a tamper-evident record of what actually happened that you can check yourself, rather than a claim you accept on trust. The two are not substitutes. A SOC 2 examines the program; per-interaction evidence examines the event.
This is the lane RankShield Legal builds in. The idea is to pair the periodic assurance of a SOC 2 with continuous, independently verifiable records that bind each AI interaction to the tool, configuration, and consent that were in force at the time, so that a firm can show what happened rather than assert it. Honesty requires two caveats. First, no record layer removes the lawyer's underlying confidentiality duty, which stays with the firm regardless of any vendor's tooling. Second, specific capabilities on our roadmap are labeled as such and should be evaluated on evidence, not on a promise. You can read how we frame that evidence in our [transparency](https://rankshieldlegal.com/transparency/) materials and our approach to firm [security](https://rankshieldlegal.com/security/). The point for this guide is narrower: a SOC 2 is where vendor verification starts, not where it ends.
5 parts of a SOC 2 report that carry the weight: type, criteria, scope, opinion, and the exceptions section

Test yourself
## Test yourself on reading a SOC 2
Four questions a legal buyer can answer from the report itself.

- 1 What is the difference between a Type I and a Type II report? Type I observes controls over time; Type II is point-in-time Type I assesses control design at a single date; Type II observes controls operating over a period They are identical **Answer:** Type I assesses control design at a single date; Type II observes controls operating over a period Type I evaluates whether controls are suitably designed as of one date. Type II evaluates whether they operated effectively over a period, commonly three to twelve months.
- 2 Which Trust Services Criterion is required in every SOC 2 report? Confidentiality Security Privacy **Answer:** Security Only Security is required. Availability, Processing Integrity, Confidentiality, and Privacy are optional and chosen by the vendor based on its services.
- 3 Which section lists the control failures the auditor actually found? The vendor's system description The exceptions in the tests-of-controls section The cover page **Answer:** The exceptions in the tests-of-controls section The tests-of-controls section records exceptions: specific instances where a control did not operate as intended during the period. It is the part most buyers never open.
- 4 What does a SOC 2 report prove? That your specific client data is safe today That specified controls were examined for a stated scope and period, with any exceptions recorded That the exact AI feature you will use is in scope **Answer:** That specified controls were examined for a stated scope and period, with any exceptions recorded A SOC 2 is a signal that an independent CPA firm tested specified controls for a defined scope and period. It does not prove your matter is safe or that the AI pipeline is covered.
Honest self-check. There is no sign-up, and nothing is stored.

Questions answered
## Straight answers to the common questions
The questions readers ask about this topic, answered directly. **No forms, no sales pitch.**

JAMIE KLONCZ · SEO AGENCY NAPLES ************** ONLINE
Pick a question on the left, or search above. You will get the direct answer, the way an answer engine would give it.

← PREV NEXT → [REQUEST ACCESS →](https://rankshieldlegal.com/contact/)

- **Is a SOC 2 report proof that a legal AI tool is safe?** No. A SOC 2 report proves that an independent CPA firm examined specified controls against the AICPA's Trust Services Criteria, for a defined scope and period, and reached an opinion with any exceptions recorded. That is meaningful evidence, but it is a signal, not a guarantee. It does not prove that your specific client data is safe, that the audited scope covers the exact AI feature you will use, or that nothing has changed since the report period closed. Read it for what it attests, then keep asking about the parts it does not reach.
- **What is the difference between a SOC 2 Type I and a Type II report?** A Type I report assesses whether a vendor's controls are suitably designed at a single point in time. A Type II report assesses whether those controls actually operated effectively over a period, commonly three to twelve months. Type II is the stronger evidence because it observes behavior over time rather than design on paper. A Type I can be an acceptable interim view for an early-stage vendor or a low-risk pilot, but for a tool that will handle privileged material, ask for a recent Type II and read its observation period.
- **Which Trust Services Criteria should a law firm look for in a SOC 2?** SOC 2 covers up to five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only Security is required in every report; the other four are optional and chosen by the vendor. For a legal AI tool, look for Security plus Confidentiality, and Privacy where the tool handles personal data. A report covering only Security is still a legitimate SOC 2, but if a vendor markets to law firms and left Confidentiality out of scope, that is a specific question worth asking before you rely on the report.
- **Why does the scope or system description matter so much?** Because a vendor's SOC 2 boundary and the AI feature you care about are not always the same. A company can hold a genuine SOC 2 covering its corporate systems and billing while the inference pipeline, model host, and prompt-logging path sit outside the audited boundary. The badge looks identical either way. Read the system description, locate the specific product and data path your firm will use, and confirm it is inside the boundary rather than in a carve-out. If the AI pipeline is excluded, the report is answering a different question than the one you need answered.
- **What is the exceptions section, and why does it matter?** In a Type II report, the tests-of-controls section lists each control, the auditor's test, and the result. Most results read as no exceptions noted, but some may record exceptions, meaning specific instances where a control did not operate as intended during the period, such as a late access review or an unapproved change. These findings matter most and are the ones most buyers never read. An exception is not automatically disqualifying; weigh whether it touches access or confidentiality, whether it repeated, and whether the management response describes real remediation. A few minor, well-remediated exceptions can signal an honest audit.
- **How recent does a SOC 2 report need to be?** A Type II report always describes a period that has already ended, so there is a gap between the period end and the day you rely on it. For fast-moving AI products, that gap matters, because a vendor may have changed its model host, sub-processors, or retention defaults since. Check the period end date and how recent it is. A common expectation is an annual cadence, so a report more than roughly a year past its period end deserves a question about when the next one is due and what has materially changed in the meantime.
- **If a vendor has a SOC 2, do we still need to verify anything ourselves?** Yes. A SOC 2 is periodic, scoped to what the vendor chose to include, and describes a past window rather than the interaction happening now. Those are structural features, not defects, but they leave room for a complementary kind of assurance: independent, ongoing verifiability, meaning a tamper-evident record of what actually happened that you can check yourself. The two work together, one examining the program and the other examining the event. Neither removes the lawyer's underlying confidentiality duty, which stays with the firm regardless of any vendor's tooling or certification.

## References

- AICPA & CIMA. System and Organization Controls: SOC Suite of Services. 2026. [https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2](https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2)
- Linford & Company LLP. Trust Services Criteria (TSCs): SOC 2 Audit Guidance. 2025. [https://linfordco.com/blog/trust-services-critieria-principles-soc-2/](https://linfordco.com/blog/trust-services-critieria-principles-soc-2/)

Written by
## [Jamie Kloncz](https://rankshieldlegal.com/about/)
Founder, RankShield
Jamie Kloncz is the founder of RankShield, the verifiable AI and quantum security platform behind RankShield Legal. An engineer by training, he built RankShield after his own devices and business were attacked, including an AI voice-cloning scam that targeted his family, on one conviction: unverifiable security is the real danger, so every consequential action should leave a receipt anyone can independently check.
[More about Jamie →](https://rankshieldlegal.com/about/)

Try it · Free
## Check a citation against live case-law
Paste a citation from an AI-drafted brief and see whether the case actually exists, resolved against live case-law. Free, no sign-up. Then request early access to certify a full filing.
[Try the citation checker](https://rankshieldlegal.com/ai-legal-citation-checker/)

Keep reading
## Related guides
[Firm Security Outside counsel guidelines are adding AI clauses: what clients now demand Read guide →](https://rankshieldlegal.com/blog/outside-counsel-guidelines-ai-clauses/)[Firm Security How to Verify a Legal AI Vendor's "We Don't Train on Your Data" Claim Read guide →](https://rankshieldlegal.com/blog/verify-legal-ai-vendor-no-training-claim/)[Firm Security How to vet a legal AI vendor: the security questionnaire that protects clients Read guide →](https://rankshieldlegal.com/blog/vet-legal-ai-vendor-security-questionnaire/)