Learn · SOC Reports
Does a SOC 2 Report Mean
You Are Secure?
No — and the distance between what the report says and what buyers hear is the source of most disappointment on both sides of the table. A SOC 2 examination provides reasonable assurance, a level the attestation standards define precisely as high but not absolute, about a specific control set, measured against specific criteria, over one past period.
Three qualifiers do all the work. Reasonable assurance, not absolute. About the controls management described, not every control that exists. Against the applicable trust services criteria, not security in the abstract.
Plain-English explainer · AT-C 105 & AT-C 205 · 2017 TSC (revised points of focus, 2022) · Last reviewed August 2026
A SOC 2 report does not say you are secure. It says an independent licensed CPA firm obtained reasonable assurance that the controls management chose to describe were suitably designed — and, in a Type 2, operated effectively — to provide reasonable assurance that the organisation’s service commitments and system requirements would be achieved, based on the applicable trust services criteria, throughout one stated period. Notice how much of that is qualification. Every clause is load-bearing, and each exists because the profession judged a broader claim could not be honestly supported. The examination runs under AT-C section 105 and AT-C section 205 — renamed Assertion-Based Examination Engagements by SSAE 21, effective for reports dated on or after 15 June 2022. It is an attestation rather than a certification: no certificate, no pass mark, and nowhere a statement that the organisation is secure. That single stated period — the observation period — is the first thing to look up when a report lands.
The defined term
The assurance level the standards actually require
In ordinary speech “reasonable” sounds like a retreat from a stronger claim. In the attestation standards it is the opposite: a specified level the practitioner must obtain, described as high but not absolute. Attestation risk is reduced to an acceptably low level; reducing it to zero is outside what the engagement contemplates. The standards name five factors for why, introducing them as factors such as the following — an illustrative list rather than a closed one.
| Factor named in the standards | What it means in a SOC 2 |
|---|---|
| The use of selective testingSamples the population | A control running many times a day across twelve months can have a population in the tens of thousands; the sample will be a few dozen. A clean sample supports an inference about the population. Inspecting the population is a different exercise, and nobody performs it. |
| The inherent limitations of internal controlControls break where people run them | Human error, collusion between two people whose duties were deliberately separated, and management override — a senior person bypassing the control they own — defeat any design. Segregation of duties raises the cost of circumvention; removing the possibility sits outside what a control set can do. |
| Evidence that is persuasive rather than conclusiveIt supports a conclusion; it stops short of proving one | An approval record persuades the auditor the approval happened. Whether the approver read what they approved lies beyond its reach. Inquiry is the weakest form and never sufficient on its own; inspection and reperformance are stronger, and certainty stays out of range for all of them. |
| The exercise of professional judgementTwo competent auditors can reasonably differ | Judgement sets materiality, control relevance, whether a population is complete, and whether a deviation is an isolated slip or a failure. |
| In some cases, the characteristics of the underlying subject matterSome things resist precise measurement | Control operation across a distributed, continuously changing production estate resists the kind of measurement a bank balance permits. There is no figure to confirm to the cent. |
A sharper point hides in the opinion itself: the phrase appears twice. The auditor obtains reasonable assurance that the controls were suitably designed to provide reasonable assurance that the service commitments and system requirements would be achieved. Two layers of “high but not absolute”, stacked — and they are distinct concepts wearing the same words. The first is the practitioner’s assurance level under AT-C section 105. The second is the internal-control sense: a control set makes a stated objective reasonably likely to be achieved, and guaranteeing an outcome lies beyond what any control set can do. Neither is absolute, which is the property they share.
The yardstick
What the criteria actually hold you to
A SOC 2 evaluates a system against suitable criteria — the 2017 Trust Services Criteria, points of focus revised in 2022. Security is mandatory, expressed as the common criteria CC1–CC9: 33 criteria spanning control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation. Availability (A1), Confidentiality (C1), Processing Integrity (PI1), and Privacy (P1–P8) sit on top and are elected by the service organisation.
Crucially, the criteria are written as outcomes. CC6.1 requires logical access security software, infrastructure, and architectures over protected information assets to protect them from security events — prescribing no password length, no MFA method, no session timeout. CC7.2 requires monitoring for anomalies indicative of malicious acts, natural disasters, and errors — naming no tooling and no detection coverage. CC8.1 governs authorised, tested, documented change without setting a bar for test coverage. So two organisations can satisfy the same criterion at very different levels of real protection, and the report treats both as meeting it. The table below makes that concrete: four criteria, the thinnest implementation that still passes, a strong one, and the question that tells you which you are looking at.
| Criterion | Minimum implementation that still passes | Strong implementation | What to ask the vendor |
|---|---|---|---|
| CC6.1Logical access security over protected information assets | SSO with MFA enforced on the admin console, a 90-day password rotation, and the VPN exempt. This is logical access security over protected assets, so the criterion is addressed. | Phishing-resistant FIDO2 across all workforce access, 30-minute privileged session timeouts, and just-in-time elevation on an expiring grant. | Which access paths are exempt from MFA — VPN, break-glass accounts, service accounts, contractor tooling? |
| CC6.2 / CC6.3Provisioning, modification, and removal of access | A quarterly access review exported to a spreadsheet and signed by the line manager. | Monthly review plus automated de-provisioning triggered by the HRIS termination record, with an exception queue for accounts the automation could not close. | What is the median time from termination in the HRIS to revocation of the last credential, and what was the longest in the period? |
| CC7.1Detecting configuration changes and new vulnerabilities | Monthly authenticated scanning with a 90-day remediation target for criticals. | Continuous scanning across build and runtime, a 7-day critical SLA, and time-boxed exceptions approved by a named owner for anything past it. | What is the remediation SLA by severity, how many criticals sit past SLA today, and how old is the oldest? |
| CC8.1Authorised, tested, documented change | A change ticket carrying one approval before deployment. | Peer review, automated test gates, and segregation between the engineer who authored the change and the identity that deployed it. | Which change paths bypass the ticket — emergency fixes, infrastructure-as-code merges, feature-flag flips, database migrations? |
Both columns earn the same clean opinion, and the report gives you no way to tell them apart from the control text alone. The criteria fix the shape of a control environment; its strength is set elsewhere, by decisions the report records and declines to grade. The same holds for the second half of the yardstick: the opinion is anchored equally to the organisation’s own service commitments and system requirements — promises written by management. A modest commitment, met, earns the same clean opinion as an ambitious one.
Who sets the exam
You describe the controls, so you shape the opinion
A SOC 2 is an assertion-based examination. The auditor arrives without a list of controls a company ought to have. Management prepares a description of the system under the AICPA description criteria (DC section 200), states which controls address which criteria, and asserts that the description is presented in accordance with the description criteria, that the controls were suitably designed, and — in a Type 2 — that they operated effectively throughout the period. The CPA firm examines that.
An applicable criterion left unaddressed is a design deficiency, and it lands in the opinion: it produces a qualified or adverse conclusion on suitability of design, or a conclusion that the description was not presented in accordance with the description criteria. Within that bound, the selection is management’s.
A narrow description does not produce a qualified opinion. It produces a clean opinion about a narrow thing.
It is worth knowing what DC section 200 does force into the open, because it is more than most readers assume. The description must disclose the types of services provided and the components of the system — infrastructure, software, people, procedures, and data; the principal service commitments and system requirements; the applicable trust services criteria together with the controls that address them, and any criteria not addressed with the reasons why; relevant details of identified system incidents; the subservice organisations used and whether the carve-out or inclusive method was applied to each; the complementary user entity controls the design of the controls assumes; and significant changes to the system during the period. Every one of those constrains what must be told. None of them constrains how wide the boundary is drawn — which is precisely how a narrow description survives the criteria intact.
The same latitude governs the system boundary: a company with four products may describe one. Two further mechanisms move work off the vendor entirely and onto you — complementary user entity controls, which the report assumes you operate, and carved-out subservice organisations, whose controls were never examined.
The ledger
What the report says, and what readers add to it
Each row pairs a real assertion the document makes with the inference readers draw from it that the document does not support. Section references throughout point at the standard five-part structure — if that is unfamiliar, start with the anatomy of a SOC 2 report: Section 1 is the auditor’s opinion, Section 2 management’s assertion, Section 3 management’s description of the system, Section 4 the controls with the tests and results, and Section 5 any other information management chooses to provide.
| What the report does say | What it does not say |
|---|---|
| The description management wrote presents the system implemented throughout the stated period, in accordance with the description criteria (DC section 200). | That it covers every product, environment, or entity the vendor operates. It covers the boundary management drew, and drawing it narrowly is permitted. |
| The controls stated in that description were suitably designed to provide reasonable assurance that the service commitments and system requirements would be achieved. | That the control set is complete or strong. Suitably designed means adequate to meet the criteria; benchmarking against a peer set never enters the exercise. |
| In a Type 2, that those controls operated effectively throughout the period, evidenced by tests whose nature, timing, extent, and results appear in Section 4. | That they operated effectively on any day after the period ended, or that untested instances outside the sample were clean. Those instances stayed unobserved. |
| That an independent CPA firm obtained sufficient appropriate evidence for a reasonable basis for the opinion, and disclosed every exception it found. | That the firm hunted for unknown vulnerabilities or tried to break in. The examination evaluates described controls; exploitation belongs to a penetration test. |
| That the assurance assumes you operate the complementary user entity controls listed, and that carved-out subservice organisations operate their own. | That the vendor is accountable for either. The opinion transfers that work to you and to the subservice organisation, in the sentence that delivers it. |
Worked contrast
Two vendors, the same opinion
Two illustrative vendors. Both hand you an unmodified Type 2 opinion for 1 April 2025 to 31 March 2026, both signed on 22 May 2026, both with zero exceptions in Section 4. The right column tells you where in the report each fact lives, so the comparison is one you can run yourself in about ninety seconds.
| Attribute | Vendor A — the narrow report | Vendor B — the broad report | Where you find it |
|---|---|---|---|
| Categories in scope | Security only. | Security, Availability, and Confidentiality. | Section 1 — scope paragraph of the auditor’s report. |
| System boundary | The hosted analytics platform — one of four products on the pricing page. | The entire production platform. | Section 3 — system-overview paragraph. |
| Controls described | 41 across the 33 common criteria; several criteria carried by a single control. | 118, several per criterion, with explicit A1.2 recovery-infrastructure and C1.1 confidentiality coverage. | Section 3 control matrix, repeated in Section 4. |
| Subservice treatment | Hosting and the managed database both carved out and unexamined. | Hosting carved out, with a tested vendor-monitoring control under CC9.2. | Section 3 — subservice organisation paragraph. |
| CUECs assigned to you | 14, including SSO enforcement and encryption-key custody. | 5, genuinely user-side — credential hygiene and configuration choices. | Section 3 — complementary user entity control table. |
| Access review cadence and sample | Quarterly; 2 tested from a population of 4. | Monthly; 5 from 12, plus a daily privilege-drift check sampled 25 times. | Section 4 — tests of operating effectiveness column. |
| Exceptions | None. | None. | Section 4 — results column, and Section 5 for management’s response. |
Vendor A told you a subset of its estate met the minimum category with a thin control set, a quarterly cadence tested twice, and fourteen obligations handed back to you. Vendor B told you the whole platform met three categories, with a daily control tested twenty-five times. Both statements are true and both were independently examined; only one is reassuring. The difference is visible in ninety seconds — and invisible forever if you stop at the word unmodified. Vendor A reappears in the next section but one, with dates attached.
The paragraph nobody reads
What the inherent-limitations paragraph actually disclaims
Between the auditor’s responsibilities and the opinion sits a short block headed Inherent limitations. It is boilerplate, which is what makes it revealing: the profession standardised the disclaimer. It makes three concessions.
One
The description is written for a broad audience
It is prepared to meet the common needs of a broad range of users and may omit aspects an individual user considers important. Your specific concern may simply fall outside it, and its absence is an ordinary consequence of the format.
Two
Controls can fail even when well designed
There are inherent limitations in any system of internal control, including human error and the circumvention of controls; because of their nature, controls may not always operate effectively. A document reporting that controls operated effectively concedes, in the same breath, that this falls short of always working.
Three
The future is explicitly excluded
Projecting any evaluation of the description, or any conclusion about design or operating effectiveness, to future periods is subject to the risk that the system changes or controls become ineffective. The report refuses, in its own words, to speak about tomorrow.
A buyer who has read those three will treat a clean SOC 2 as evidence with stated edges. A vendor who has read them will stop marketing it as a warranty.
Both can be true
How a breach happens under an unmodified opinion
It happens regularly, and each time someone concludes SOC 2 is theatre. The accurate conclusion is that the two statements were always about different things. Four reasons cover almost every case.
- 1
The event was outside the boundary
The compromised asset sat in a product, environment, or entity the description did not cover, or inside a carved-out subservice organisation. The examined system behaved exactly as reported. Vendor A described one of four products; three of them were never examined at all.
- 2
The event was after the period
Vendor A’s period closed on 31 March 2026 and the report was signed on 22 May. An intrusion beginning in July sits outside both dates, and the inherent-limitations paragraph says as much. A control that operated effectively for twelve months can be disabled on day 366 by a single change.
- 3
The control met the criterion and was still too slow
The criteria are written as outcomes. Quarterly access reviews satisfy CC6.2 and CC6.3; a credential compromised in week two of a quarter has eleven weeks of use before the next review. Monthly scanning satisfies CC7.1; that offers little against an exploit weaponised in seventy-two hours. Nothing failed. The bar was met, and the bar was low.
- 4
The failure was in the untested remainder, or in a CUEC nobody operated
A sample of 25 from 8,000 offboarding events leaves 7,975 instances unobserved — selective testing is named in the standards for exactly this reason. And where the breach traces to an assumed complementary user entity control, the report had already assigned that work to the customer, in writing, in Section 3.
Vendor A, carried forward
Seventy-eight days of standing access, under a clean opinion
31 Mar 2026
The observation period closes. Twelve months of described controls are now history.
22 May 2026
The report is signed. Section 4 shows zero exceptions; the quarterly access review was tested twice from a population of four, and both selections were performed, evidenced, and actioned.
3 Jun 2026
You receive the report under NDA, read the opinion, and approve the vendor.
14 Jul 2026
A contractor’s credential is phished. The account is legitimate, in scope, and was provisioned exactly as CC6.2 requires.
14 Jul – 30 Sep 2026
The credential carries standing access for seventy-eight days. Vendor A’s access review runs quarterly, and the next one falls due on 30 September.
30 Sep 2026
The review runs on schedule, the contractor account is flagged as no longer required, and access is removed. The control worked exactly as described.
Every sentence in the FY26 report remains true. CC6.2 and CC6.3 were satisfied before, during, and after. The report covers 1 April 2025 to 31 March 2026, and the intrusion happened in July. Now run the same 14 July against Vendor B: a daily privilege-drift check, sampled twenty-five times by the auditor, surfaces the same credential inside twenty-four hours. Same criteria, same clean opinion, seventy-seven days of difference. That gap is invisible in the opinion and plainly visible in Section 4.
A fifth possibility deserves naming: the report was wrong. Judgement is exercised, evidence is persuasive rather than conclusive, and management can withhold — which is why auditor independence is regulated, licensed, and inspected. It is also the rarest of the five.
Evidence
What the CPA firm actually asks for
Testing runs in a fixed order. The auditor first establishes the population — every instance of the control across the period, so for offboarding, every departure between the first and last day, rather than every departure the HR system shows today. Then they establish that it is complete, a harder problem than producing it. Only then do they select and test against defined attributes. More on the mechanics in evidence collection.
| Control frequency | Population / 12 months | Typical sample | What it means for you |
|---|---|---|---|
| Annual | 1 | 1 | Examined in full — the annual risk assessment, the yearly DR test. |
| Quarterly | 4 | 2 | Usual for access reviews. One missed quarter is a 25% population deviation rate — and 50% of a two-item sample if it lands in the selection. |
| Monthly | 12 | 2–5 | Scan review, backup verification, log sign-offs. Small populations are unforgiving. |
| Weekly | 52 | 5–15 | Selections spread across the whole period; the auditor deliberately straddles quiet months and busy ones. |
| Daily | ~250–365 | 20–40 | Backup completion, alert triage — including the weeks you were mid-migration. |
| Event-driven | Every occurrence | 25–60 | Changes, joiners and leavers, access grants. The hard part is proving completeness. |
Sample sizes reflect common service-auditor practice; the AICPA publishes no mandated table. The standards require the auditor to consider the nature of the control, the homogeneity of the population, the frequency of application, and the expected deviation rate — the reasoning is set out in SOC 2 sampling and sample sizes.
There is a term for the material at the centre of all this: information produced by the entity, or IPE. Any report, export, query result, or list the organisation generates and hands over is IPE, and the auditor must evaluate its accuracy and completeness before relying on it as audit evidence. That single requirement explains every request that feels bureaucratic — the source system, the exact filter or query, the generation timestamp, the operator, and a row count tying the export to the system’s own total. Absent those, the file is a claim about the population rather than the population itself.
A strong evidence artefact
- A system-generated export showing the source system, the query parameters, the generation date, and the operator — with all four still visible.
- A row count tying the on-screen system total to the exported file, so completeness is demonstrated on the page.
- A ticket with request, independent approval, implementation, and closure — timestamps in order, approver distinct from requester.
- For a periodic review: the artefact reviewed, the reviewer, the date, and the action taken. A sign-off carrying no consequence is a signature.
What gets rejected
- A spreadsheet with no provenance. IPE earns the status of evidence once the auditor can see how it was generated, and until then it is a file.
- Screenshots cropped to hide the URL bar, the clock, or the filter applied. Context is what makes a screenshot evidence.
- A population that cannot be shown complete — an ad-hoc query nobody can reproduce, or an export from a system outside the tested environment.
- Evidence produced retrospectively. An access review reconstructed in April for a January cadence gets written up as an exception.
- Inquiry alone. “We do this every month” is never a test result.
The four procedures
Section 4 names the procedure used for every control it lists, and the four differ sharply in what they can support. Scanning that column is the fastest quality read available to a buyer.
| Procedure | What it establishes | What it leaves open | On an offboarding control |
|---|---|---|---|
| Inquiry | That a process is described, and by whom. | Whether it ran even once. On its own it is never a sufficient test. | “We revoke access within one business day of termination.” |
| Observation | That the control runs at the moment the auditor watches it run. | Anything about the remaining 364 days of the period. | Watching an administrator perform a revocation in the directory. |
| Inspection | That a specific instance ran and left a durable record. | What the reviewer actually considered before signing. | The offboarding ticket plus the directory audit-log entry showing the disable action and its timestamp. |
| Reperformance | That the control’s outcome is correct, verified independently by the auditor. | Whether the same rigour applied on the instances the auditor did not reperform. | The auditor queries the directory themselves for accounts belonging to terminated employees and checks each status. |
What happens when a deviation turns up
Say one of twenty-five offboarding selections shows an account still live nine days after termination. The auditor works a defined sequence. Establish what happened and why, because an isolated slip and a broken process carry different consequences. Consider extending the sample, since one deviation in a sample sized on an expectation of none changes the expected deviation rate for the whole population. Obtain management’s response. Write it into Section 4 as an exception, naming the nature of the deviation, the population, the number of items tested, the number of deviations, and any remediation. Only then does the separate question arise of whether the opinion itself moves. The order matters: the exception gets disclosed whether or not the opinion changes, which is why exceptions appear under clean opinions so often.
Notice what all that rigour is aimed at: whether the described control was performed, by whom, when, and with what result. No procedure asks whether it was strong enough for your threat model. Evidence discipline is what makes the report trustworthy about what it covers, and it is also what keeps that coverage narrow.
The wider shelf
What each assurance artifact actually evidences
If a SOC 2 answers a bounded question, the sensible follow-up is which artifact answers the rest. Six of them circulate in vendor diligence, and they evidence genuinely different things over genuinely different windows.
| Artifact | What it evidences | Period it speaks to | What it leaves open |
|---|---|---|---|
| SOC 2 Type 2 | Independent testing of a described control set against the applicable criteria, with populations, samples, procedures, and results disclosed control by control. | A closed past period, commonly 3 to 12 months. | Exploitability, control strength relative to your threat model, and anything outside the described boundary. |
| SOC 2 Type 1 | That the described controls were suitably designed and implemented. | A single date. | Whether any of them ever operated. There is no population, no sample, and no results column. |
| SOC 3 | The same examination, summarised for general use: the opinion plus an abbreviated system description. | The period of the underlying Type 2. | Everything Section 4 carries — populations, samples, test procedures, results, exceptions. |
| ISO/IEC 27001 certificate | That a certification body found a management system conforming to the standard, scoped by a Statement of Applicability covering the Annex A controls. | A three-year certification cycle with surveillance audits in between. | Test results. The certificate discloses none — ask for the Statement of Applicability and the scope statement. |
| Penetration test report | Whether a skilled tester achieved defined objectives against the system as configured during the test window. | A few days, usually. | Whether findings were fixed, and whether the same weakness recurs test after test. Ask for the retest evidence. |
| Security questionnaire (SIG, CAIQ) | What the vendor says about itself, in a format comparable across vendors. | Whatever the respondent had in mind on the day. | Everything, until examined. No independent party checked a single answer. |
Read down the last column and the diligence programme writes itself. A Type 2 plus a current penetration test with retest evidence plus contractual commitments covers most of what a questionnaire only asks about. On the choice between the two most-compared artifacts, see SOC 2 vs ISO 27001, and which comes first.
Edge cases
Where this gets contested
A breach occurred during the period and the opinion is still clean
Entirely possible. DC section 200’s system-incidents criterion (DC4) requires disclosure of identified incidents that either resulted from controls that were not suitably designed or operating effectively, or otherwise caused a significant failure to achieve the service commitments and system requirements — a narrower trigger than “all incidents”, and a useful one to know when reading Section 3. CC7.4 separately requires a defined incident-response programme. If controls operated as described and the incident was identified, contained, and communicated through that programme, the auditor may find no deviation. An incident tests the control environment; failing it is a separate finding.
Exceptions in Section 4 under an unmodified opinion
Exceptions are disclosed findings; the opinion is a materiality judgement about them in aggregate. A qualified opinion is a strong signal precisely because it is rare. Read the exception text, the criterion it touches, the population and items tested, and management’s response in Section 5.
A Type 1 offered as evidence of security
A Type 1 opines on design as of a single date: no operating-effectiveness testing, no population, no sample, no results column. It evidences a control set implemented on one day — a reasonable milestone, and a poor substitute for a period report.
Penetration testing treated as a SOC 2 requirement
The criteria do not name penetration testing. Vulnerability scanning appears in the points of focus under CC7.1, and a pen test is the usual way organisations evidence parts of the risk-assessment and monitoring criteria — common practice, and the criteria stop short of requiring it.
A subservice organisation carved out of the thing you care about
Under the carve-out method that organisation’s controls are excluded from the description and from testing; the report merely assumes complementary controls exist there. If the carved-out party runs your data plane, your assurance stops at the vendor’s doorstep and the right next step is that provider’s own report.
A “SOC 2 certificate” or tool badge instead of a report
There is no SOC 2 certificate, no accrediting registry, and no logo carrying an opinion. A badge evidences a subscription. The report is the only artefact carrying the opinion — and it is restricted-use, so expect an NDA rather than a download link.
More on two of these: a security incident during the observation period and SOC 2 and penetration testing.
Objection handling
What a buyer’s security team pushes back on
None of these is unfair and none is fatal. Each answer concedes what is true, names the exact place in the report that settles it, and states the follow-up artefact to ask for.
“Your SOC 2 does not tell me you are secure.”
Correct, and we would not claim otherwise. What it tells you is narrower and checkable: an independent licensed CPA firm defined a population for each described control, selected from it, tested against stated attributes, and disclosed every deviation in Section 4. Read the test-procedure column there — a control evidenced by inquiry alone is a weaker result than one evidenced by inspection or reperformance, and the column tells you which you got. For exploitability, the artefact is the penetration test, and the useful ask is the executive summary plus retest evidence for anything rated high or critical. The two answer different questions. A buyer holding both is in a materially better position than one holding either.
“How do I know the scope is not gamed?”
Fair — the boundary is management’s to draw. Open Section 3 and find the system-overview paragraph: the description criteria require it to name the infrastructure, software, people, procedures, and data in scope. Check three things. That the product named matches the one on your order form, rather than the parent brand. That the environment named is production, rather than a single region or a staging subset. That the legal entity matches the one on your MSA. Then read the subservice paragraph — if your data plane runs on a carved-out provider, that provider’s controls were never examined. If any of the three fail to match, the report is accurate and irrelevant to you, and the right ask is a written scope confirmation from the vendor’s CISO.
“You had exceptions. Why is the opinion still clean?”
Because those are separate judgements. An exception is a deviation the auditor found and disclosed; the opinion is a materiality assessment of the deviations in aggregate against the applicable criteria. Read the exception text in Section 4 for four things: which criterion it touches, the size of the population, how many deviations appeared in how many items tested, and whether management’s response in Section 5 describes a completed remediation with a date or an intention with none. One late access review in a quarterly population of four is a different fact from three late ones. The signal that should genuinely move you is an exception recurring across two consecutive periods — a control that was never fixed, disclosed twice.
“Security is not enough. I need availability and confidentiality.”
Then check the scope line in Section 1 before anything else. Security is mandatory; Availability, Confidentiality, Processing Integrity, and Privacy are elected by the service organisation, and a report scoped to Security alone examined none of them at any depth. If you carry an uptime commitment to your own customers, an Availability-scoped report tests capacity monitoring (A1.1) and recovery infrastructure, backups, and environmental protections (A1.2) — go to the recovery-test control in Section 4 and read how large the population was and how many instances were selected. Adding a category takes a fresh observation period, so the realistic ask is a commitment to widen the scope for the next window, plus contractual availability terms to cover the interval.
“Your period ended nine months ago.”
Fair, and the report concedes it in writing: projecting any conclusion to a future period carries the risk that the system changed or that controls became ineffective. The honest answer is two dates — when the current period started and when it closes — plus a list of what changed. Ask for that list, since the description criteria require significant changes during a period to be disclosed in the report covering it. A bridge letter is management’s own statement that nothing material changed between period end and the letter date; it carries no auditor testing and no opinion. Treat it as a representation you can hold the vendor to contractually, diary the next report date, and make delivery of it a contractual obligation.
“You use a compliance automation tool. Does that not auto-pass everything?”
No. The platform collects and monitors evidence; issuing an opinion sits with the CPA firm, and the auditor must still evaluate whether information produced by the entity — which includes every export the platform generates — is accurate and complete before relying on it. In practice that means showing the source system, the query or filter behind the export, the generation timestamp, and a row count that ties to the system’s own total. A green dashboard is a readiness signal from a tool the vendor configured. The examination is what tests whether the underlying control ran. Compare the platform’s control list against Section 4 if you want to see the gap: only one of them carries populations, samples, and deviations.
“Your auditor is a firm I have never heard of.”
A reasonable check, and it resolves to something verifiable rather than a matter of trust. Only a licensed CPA firm can perform the examination and sign the opinion, and that licence is issued by a state board of accountancy — you can confirm the firm and its standing directly with the relevant board’s register. Firms enrolled in the AICPA Peer Review Program are reviewed on a three-year cycle; ask for the most recent peer review report and for the firm’s SOC engagement experience in your industry. Then read the opinion page, which names the firm, its city, and the report date. A boutique firm is ordinary and unremarkable. A firm that cannot produce a licence number is the actual signal.
“You changed auditors between periods.”
Usually mundane: fee, capacity, a partner move, a larger user-entity base demanding a bigger firm, or a firm exiting SOC work altogether. The concern worth naming plainly is opinion shopping — a change made because the prior firm was heading towards a qualification. Two questions separate the cases. Ask why the change happened, and whether the prior period’s report is still available to you; a vendor willing to share both periods is behaving normally. Then compare the two Section 4s for the controls you care about: the same control described with a materially thinner test procedure or a smaller sample after the switch is worth a conversation. A change arriving alongside a scope reduction in the same period is the pattern to press on.
“Your Section 4 control text looks templated.”
It often is, and on its own that proves little in either direction. Most organisations build their control set from a compliance platform’s library or from their auditor’s mapping, so identical wording across unrelated vendors is ordinary. Templated text becomes a problem only where the control describes something the organisation does not actually do — and the columns that expose that sit to the right of the text. Read the population, the number of items tested, the test procedure, and the result. Boilerplate survives contact with an auditor in exactly two places: a control tested by inquiry alone, and a population left undefined. Pick three controls that matter to you, read across each row, and ask the vendor to walk you through how the evidence for one was produced.
“You will not send me the report.”
A SOC 2 report is a restricted-use document: its use is limited to management, user entities, and other specified parties who understand the assumptions behind it, which is why an NDA is the normal condition of access rather than an obstacle. Expect to sign one, expect a watermarked PDF, and expect a named recipient list. What you can reasonably ask for before signing is the period dates, the categories in scope, the auditor’s name, and whether the opinion is unmodified. What is a genuine signal is a vendor who declines to share the report under NDA at all, or who offers a tool badge or a SOC 3 summary in its place and treats the substitution as equivalent.
Two of these have guides of their own: bridge letters and what they carry and opinions and exceptions.
Take this to the vendor
What to ask, and where the answer lives
Ten questions, each with the place in the report that settles it. Every line stands on its own, so any of them can be pasted straight into an email to a vendor.
01
Does the described system name the product on my order form?
Section 3 — management’s description of the system, system-overview paragraph.
02
Which trust services categories are in scope?
Section 1 — the independent service auditor’s report, scope paragraph.
03
Is this a Type 1 or a Type 2, and what exactly are the period dates?
Section 1 — a Type 2 names a period; a Type 1 names a single as-of date.
04
Which subservice organisations are carved out, and do any of them hold my data?
Section 3 — subservice organisation paragraph, then the CSOC table if one is present.
05
How many complementary user entity controls are assigned to me, and who owns each internally?
Section 3 — CUEC table. The owner column is yours to fill in.
06
What cadence does the access review run at, and how many instances were tested?
Section 4 — the control description, then the tests of operating effectiveness column.
07
Which controls were tested by inquiry alone?
Section 4 — test procedure column. Scan it for the controls that matter to you.
08
Were there exceptions, and does management’s response name a completed remediation or an intention?
Section 4 results column, then Section 5 — other information provided by management.
09
Were there significant changes to the system during the period?
Section 3 — the description criteria require significant changes in the period to be disclosed.
10
When did the period end, and when does the next one close?
Section 1 for the end date. The next date comes from the vendor, in writing, in the contract.
Ten answers take an hour to gather and will tell you more about a vendor than the opinion page ever will. Where an answer is missing from the report, that absence is itself the finding — and the follow-up belongs in the contract, where it can be enforced.
The positive case
What a SOC 2 report does legitimately evidence
Everything above draws boundaries. Inside them the report is unusually good: an independent licensed CPA firm, bound by independence and ethical requirements, examined a written description against published criteria and reached a documented opinion. A control set exists, is mapped to criteria, and was operating — in production, month after month — with tests and results disclosed exception by exception.
It also evidences a functioning control culture, which is harder to fake than a document. A twelve-month Type 2 resists assembly in the week before a deal closes: it requires that access reviews happened in month three, that changes were approved by someone other than the engineer who wrote them, and that somebody kept the artefacts.
So use it as one input alongside the penetration test, the architecture review, the contractual commitments, the incident history, and your own questionnaire. As one input it is excellent. As the whole answer it will eventually disappoint you — and the report told you so, in the paragraph you skipped.
Does SOC 2 Mean Secure? — Common Questions
What reasonable assurance means, what the report covers, and where the limits sit.
Does a SOC 2 report mean a company is secure?
No. It means an independent licensed CPA firm obtained reasonable assurance that the controls management described were suitably designed — and, in a Type 2, operated effectively — against the applicable trust services criteria over one stated period. Every element is bounded: the assurance level, the control set, the criteria, and the period. The word “secure” never appears in the opinion, and the inherent-limitations paragraph declines to project the conclusions forward. What it does give you is checkable: a written system boundary, a control set mapped to criteria, the population and sample for each test, and every exception the auditor found, disclosed in Section 4.
What does “reasonable assurance” actually mean in a SOC 2?
It is a defined level in the attestation standards, and it is specified: high, but not absolute. AT-C section 105 explains that attestation risk is reduced to an acceptably low level rather than to zero, and lists factors such as selective testing, the inherent limitations of internal control, evidence that is persuasive rather than conclusive, professional judgement, and the characteristics of the underlying subject matter. Note that the phrase appears twice in the opinion: the auditor obtains reasonable assurance that controls were suitably designed to provide reasonable assurance that commitments would be met. The first is the practitioner’s assurance level; the second is the internal-control sense.
Why is absolute assurance impossible in a SOC 2 examination?
Because of how the evidence works. The auditor selects rather than examines every instance: a sample of 25 from 8,000 offboarding events in a twelve-month period leaves 7,975 instances unobserved, so a clean sample supports an inference about the population rather than an inspection of it. Internal control can be defeated by human error, by collusion between two people whose duties were deliberately separated, and by management override. Most evidence supports a conclusion rather than proving one — an approval record shows an approval happened, and stops there. And materiality, population completeness, and sample sizing are all judgement calls two competent auditors could make differently.
Can a company with a clean SOC 2 report suffer a data breach?
Yes, and both statements can be true at once. Take a vendor whose period ran to 31 March 2026 with a report signed on 22 May and zero exceptions. A contractor credential is phished on 14 July. The vendor’s access review is quarterly and the next one falls due on 30 September, so the credential carries 78 days of standing access before the review catches it — exactly as designed. CC6.2 and CC6.3 were satisfied throughout, and nothing in the report covers July. The other common patterns: the asset sat outside the described boundary, or inside a carved-out subservice organisation, or the failure was a complementary user entity control the customer never operated.
What does a SOC 2 report actually prove?
That a described control set existed, was mapped to the applicable criteria, and was operating over months, verified independently with disclosed tests and results. It also proves something harder to fake: the organisation sustained those controls long enough to be sampled across the whole period. A twelve-month Type 2 resists retrospective assembly, and that evidenced consistency is far more than a questionnaire response. It gives you a written boundary you can interrogate, a list of obligations transferred to you as CUECs, and a disclosed exception list — four things a badge or a self-assessment never supplies.
Do the trust services criteria set a minimum security standard?
Not in the way buyers expect. The criteria are written as outcomes. CC6.1 requires logical access controls over protected information assets; it specifies no password policy, MFA method, or session timeout. So a vendor with SSO plus MFA on the admin console, a 90-day password rotation, and the VPN exempt satisfies CC6.1 — and so does a vendor running phishing-resistant FIDO2 across all workforce access with 30-minute privileged session timeouts and just-in-time elevation. Both earn the same clean opinion, and the control text alone will rarely tell you which you are reading. The question that separates them is which access paths are exempt from MFA.
Is a SOC 2 report the same as a penetration test?
No, and they overlap very little in what they evidence. A penetration test reports exploitability against the system as configured during a test window of a few days: it tells you whether a skilled attacker achieved defined objectives today. A SOC 2 reports whether described controls operated across a closed past period of months, with populations, samples, and disclosed results. One speaks to current attack surface; the other to sustained control operation. The criteria do not name penetration testing — vulnerability scanning appears in the points of focus under CC7.1, and a pen test is the usual supporting evidence for risk-assessment and monitoring criteria. They are complements, and a buyer should ask for both.
If exceptions are listed, does that mean the controls failed?
Not necessarily. An exception is a deviation the auditor found and disclosed. When one turns up, the auditor establishes root cause, may extend the sample because a deviation in a sample sized on an expectation of none changes the expected rate for the population, obtains management’s response, and writes up the nature of the deviation, the population, the items tested, the deviations found, and any remediation. Only then does the separate question arise of whether the opinion moves. So isolated deviations with contained impact and evidenced remediation routinely sit beneath an unmodified opinion. The signal that matters is an exception recurring across two consecutive periods.
How is a SOC 2 different from ISO 27001 for judging whether a vendor is secure?
They give you different evidence in different formats. A SOC 2 Type 2 is an attestation report you read: it contains the system description, the control set, the test procedures, the populations and samples, and every exception — so you can assess the strength of individual controls yourself. An ISO/IEC 27001 certificate evidences that a certification body found a conforming management system, scoped by a Statement of Applicability covering the Annex A controls, over a three-year cycle with surveillance audits. The certificate itself discloses no test results, so the useful asks are the Statement of Applicability and the scope statement. Many organisations hold both, and enterprise buyers increasingly expect it.
Does TCSA issue SOC 2 reports?
No. Only a licensed CPA firm can perform the examination and sign the opinion. Tranquility Cybersecurity prepares organisations for it — readiness assessment, control design and remediation, system description drafting, evidence and population preparation, and CUEC design — and coordinates the examination with independent licensed CPA firms. We never certify, attest, audit, or sign. Keeping those roles separate is a condition of the auditor’s independence.
Related reading: how to read a SOC 2 report, the anatomy of the five sections, opinions and exceptions, scope and system boundary, sampling and sample sizes, how long a report stays usable, CUECs and CSOCs, certified vs attested, and the SOC 2 hub.
Written By Expert Auditors
Keep Exploring
Related Reading
What Is SOC 2?
The AICPA attestation explained — five categories, Type 1 vs Type 2, report not certificate.
Read moreSOC 2 Opinions & Exceptions
Unmodified, qualified, adverse, disclaimer — and why exceptions are not qualification.
Read moreHow to Read a SOC 2 Report
All five sections annotated, an 8-step reviewer checklist, and the red flags.
Read moreIs There a SOC 2 Certificate?
There is no SOC 2 certification — what you may legitimately claim, and the wording that costs you credibility.
Read moreSOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreDoes SOC 2 Make You GDPR or DPDP Compliant?
What SOC 2 genuinely supports in each regime, and the obligations it never touches.
Read moreGet in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours