SOC 2 for a UI person
SOC 2 is an attestation report about controls, not a certification and not a security standard — and the reason a front-end telemetry choice lands inside its scope is the part almost nobody explains.
You are three slides into a design review at a portfolio company. You raise the telemetry question from the data module — what does this replay tool mask on the review gate — and somebody answers, pleasantly, that the vendor is SOC 2 compliant.
That sentence is doing two jobs. It is answering your question, and it is ending the conversation. This lesson is about why it does neither, and about the one mechanism inside SOC 2 that makes a front-end dependency choice into somebody else’s audit problem.
What the standard-setter actually says it is
AICPA, which writes the criteria, describes the thing in one sentence:
“A SOC 2 examination is a report on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy.” (AICPA & CIMA)
Three words in there are load-bearing. Report — the output is a document somebody reads, not a status a database holds. Controls — the subject is what the organisation says it does, not the software. Relevant to — the scope is chosen, not fixed.
The structure underneath is an attestation engagement. AICPA’s logo guidelines describe the reports as “examination engagements performed by a service auditor in accordance with SSAE No. 18… AT-C section 105… and AT-C section 205”, issued by a licensed CPA, and the logo itself is a twelve-month licence tied to a report. A licensed accountant examined a described system and expressed an opinion, for a period, against criteria the organisation helped scope.
The sentence not to borrow
You have read “SOC 2 is not a certification” a hundred times. AICPA does not say it. Not in the topic page, not in the criteria, not in the logo guidelines — every source using that exact phrasing is a compliance-automation vendor or an audit-firm blog. The claim is defensible as a description of the structure and it is not a quotation, so do not deliver it as one in front of the person who reads these reports for a living. Say the structure instead: examination engagement, licensed CPA, an opinion covering a period.
Two dimensions that a badge collapses
A logo on a marketing page hides two independent variables, and both of them are the thing you were actually asking about.
Type. The Description Criteria state plainly that “there are two types of SOC 2 examinations (type 1 and type 2)”, with type 2 adding “the operating effectiveness of controls.” Type 1 is design at a point in time. Type 2 is design plus whether the controls actually ran, over a stated period. Same logo.
Scope. There are five trust services categories — security, availability, processing integrity, confidentiality, privacy — and a report may cover one, or several. The 2017 Trust Services Criteria describe the common criteria as “criteria common to all five of the trust services categories”, sufficient on their own for security, with the other four categories adding criteria on top.
The mechanism that makes this yours: subservice organizations
Here is the part almost nobody explains, and the reason this lesson is in a front-end course at all.
The Description Criteria define a subservice organization as “a vendor used by a service organization that performs controls that are necessary, in combination with controls at the service organization…” to meet the company’s own commitments. The same document notes that a vendor “might also be a subservice organization.” Vendor is a commercial relationship. Subservice organization is an audit relationship, and one can quietly become the other.
Then the company has to pick a method, and DC7 governs which:
- Carve-out. The subservice organization’s system components “are excluded from the description… and from the scope of the examination.” The report says the vendor is there and says nothing about its controls.
- Inclusive. Its controls “are subject to the service auditor’s examination procedures.” The vendor is inside the audit.
One description can carve out some subservice organizations and include others. So “our vendor is in our SOC 2” and “our SOC 2 says nothing about that vendor” can both be true statements about the same report, depending on which vendor you meant.
Now put your own work in that frame. You add a session-replay SDK, an error monitor or a trace viewer to a shared agentic component kit. That kit lands in products whose customers ask for a SOC 2 report. If the recorded surface carries data the company has made confidentiality or privacy commitments about, the tool is a candidate subservice organization — and the person who decides carve-out or inclusive has not been told the tool exists, because a dependency arrived in a design system, not in a procurement thread.
That is the flag. Not “this breaks compliance.” It almost certainly does not. The flag is that a front-end decision moved something across an audit boundary, and the person who owns the boundary does not know.
Why the explainers are not your source
Search for what SOC 2 is and you will be handed page after page by Vanta, Drata, Secureframe, Sprinto and their peers. They are not careless. They are selling compliance automation and remediation, which means their explainers are shaped by what they can sell you next, and that shaping is exactly where the two errors above come from: the “required category” framing and the “not a certification” sentence are both vendor phrasings that AICPA does not use.
AICPA has published its own, vendor-independent FAQs on the effect of software tools on SOC 2 examinations, acknowledging that “a number of software solutions…have been introduced that are designed to improve the efficiency with which service organizations can prepare for and undergo SOC 2 examinations.” A limit worth stating: the PDF behind that page is account-gated and this course has only verified the page-level snippet, not the full document.
Check your recall
Answer from memory — no scrolling back.
Retrieval check
Someone says “we are SOC 2 Type 2, so the review gate is fine.” What has that sentence not answered?
Check your answer
Whether the review gate was in the described system at all, whether confidentiality or privacy were in scope or only the common criteria, what period the examination covered, and whether the replay vendor was carved out. A type 2 report is a real thing and it is a report about the controls the organisation described, over a period it chose, against categories it selected.
The follow-up that works is not a challenge. It is: “which categories, and is the replay vendor carved out or included?” That question has a document-shaped answer, and the compliance owner can produce it in a day.
Hands on
Turn one dependency into a compliance-shaped question
Done when: One written question, under forty words, naming a specific third-party SDK on a specific surface, using the words subservice organization and carve-out correctly — plus one sentence stating what you are not claiming. Checked against AICPA’s own definitions rather than a vendor explainer.
- Pick one third-party script that runs on a surface rendering personal data. The review gate is the sharpest example, because it displays a document crop and extracted fields at the same time.
- Open the Description Criteria page and read the two method definitions. They are short. You are looking for the exact wording of carve-out and inclusive, because using them loosely is worse than not using them.
- Write the question. Name the tool, name the surface, and ask whether the tool is a subservice organization for the company’s report and, if carved out, whether the report says anything about its controls.
- Write the limit. One sentence, starting “I am not claiming…”. If you cannot write it, you have a suspicion rather than a flag.
- Read both sentences aloud. If the question contains a proposed remedy, delete the remedy. You are not the compliance owner and the remedy is how the flag turns into an argument.
- Put it in the
FLAG-LOG.mdrow for that surface, in the “question I would ask” and “what I am not claiming” columns. Leave the owner column blank for now.
What this does not cover
This lesson gave you one vocabulary and one boundary. It did not tell you who to send the question to, and the owner column in your flag log is still empty on purpose. The compliance owner is the right destination for the carve-out question and the wrong destination for at least three other flags you are carrying, including every one from the data module. The next lesson, on who owns the answer, is where that column gets filled in — and where a flag with two owners turns out to be two flags.
It has also said nothing about how to read a SOC 2 report, prepare for an examination, or assemble evidence for one. That is the compliance owner’s craft, it takes years, and this course’s ceiling puts it firmly outside what you should be doing.
Read this next — primary source
2018 SOC 2 Description Criteria (With Revised Implementation Guidance – 2022)AICPA & CIMA — page dated 9 July 2025, live 2026-09-05. The standard-setter itself, which is the point: almost everything else written about SOC 2 is published by companies that sell compliance remediation.
This lesson takes the definitions that decide whether a vendor you added lands inside somebody else’s audit: subservice organization, and the carve-out and inclusive methods. Read the definitions section rather than the whole document — DC7 is the criterion that governs, and the two method definitions are about a paragraph each. Where it stops: it tells you how a description of a system must be written, not whether any given control is any good. Nothing in it will tell you a session-replay SDK is a bad idea.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.