SOC 2 (System and Organization Controls 2)

A SOC 2 report isn't a public certificate. It's typically shared directly with a customer or prospect under an NDA, which means a risk team usually has to ask for it rather than verify it against a public registry the way it might check an ISO 27001 certification.

What Are the Five SOC 2 Trust Services Criteria?

An auditor tests a vendor's controls against up to five Trust Services Criteria, but only one of them is required in every SOC 2 report. The vendor and its auditor scope the engagement to the criteria that actually match what the vendor promises its customers.

• Security. Protection against unauthorized access, the one criterion every SOC 2 report includes.
• Availability. Whether systems are available for operation as committed.
• Processing integrity. Whether system processing is complete, accurate, and authorized.
• Confidentiality. Protection of information designated as confidential.
• Privacy. How personal information is collected, used, retained, and disposed of.

Security Is the One Mandatory Criterion

Because every SOC 2 report includes Security, it's often called the common criteria. A vendor can hold a clean SOC 2 report that never tested Availability or Privacy at all, which matters if a buyer assumed the report covered everything the vendor does.

What's the Difference Between a SOC 2 Type I and Type II Report?

A Type I report evaluates whether controls were designed correctly on a single date; a Type II report evaluates whether those controls actually worked over a period of months.

Type I Confirms Controls Are Designed Correctly

An auditor reviews policies, configurations, and documentation as of one point in time and opines on whether the control design is suitable. It says nothing about whether the control operated as intended the week before or the week after.

Type II Confirms Controls Worked Over Time

An auditor tests evidence across a defined window, commonly six to twelve months, to confirm controls operated consistently throughout the period, not just on the day someone checked. Enterprise buyers increasingly treat Type II as the baseline expectation rather than an upgrade.

How Long Does a SOC 2 Report Stay Current?

Most organizations renew a SOC 2 report annually, so a report covering last year's audit period says nothing about what changed in the months since it closed. A vendor's Type II window ends on a specific date, and the report a buyer reads today may already be describing a control environment the vendor has since changed, for better or worse. A vendor that switched cloud providers, replaced a key vendor of its own, or responded to an incident after the audit period closed carries none of that history in the report a buyer is holding.

This is also where a compliance completeness rating adds something a single report can't. It measures how much of a given framework Black Kite was able to evaluate from a vendor's externally facing assets and uploaded documents, which sets the boundary on what any compliance figure can actually speak to.

What Can a SOC 2 Report Not Tell a Risk Team?

A SOC 2 report only covers the Trust Services Criteria the vendor chose to scope in, and even an unqualified opinion only speaks to the audit period that already closed. Black Kite's 2026 Supply Chain Vulnerability Report found that found that attackers now exploit vulnerabilities an average of seven days before public disclosure, and that the handoff from initial access to a ransomware operator takes a median of 22 seconds. A control environment an auditor tested six months ago is being measured against a timeline that no longer resembles the one the audit assumed.

• A narrow scope. A report covering only Security says nothing about Availability or Confidentiality, even if the vendor implies otherwise.
• A qualified opinion. An auditor can note exceptions and still issue a report; a buyer skimming the cover page can miss that the opinion wasn't clean.
• A closed audit period. The report describes a window that already ended, not the vendor's environment today.

How Does a SOC 2 Report Differ From an ISO 27001 Certification?

The distribution model is the clearest difference. A SOC 2 report is a restricted document shared under NDA, while an ISO 27001 certificate is a public credential a buyer can verify against an accreditation body's registry. SOC 2 also lets a vendor choose which Trust Services Criteria apply, while ISO 27001 works from a single reference list of controls every certified organization draws from. Neither difference makes one stronger than the other. A buyer evaluating both documents is really asking two different questions. Did a specific set of controls work over a period, or did a broader management system pass an audit against a global standard?

What Should a Risk Team Do With a Vendor's SOC 2 Report?

The organization requesting the report is the one that has to actually read it, since a cover letter summary can miss what the report itself qualifies or excludes.

• Check the opinion type, unqualified or qualified, before treating the report as a clean bill of health.
• Confirm which Trust Services Criteria are in scope, not just that a SOC 2 report exists.
• Note the audit period's end date, and pair it with continuous monitoring or an outside-in assessment to cover the gap since.

A vendor's SIG response often cites the SOC 2 report as supporting evidence for specific questions, and a continuously updated cyber rating covers the period a report can't, the time since the audit closed.

How Does Black Kite Use SOC 2 Reports in Its Compliance Workflow?

Black Kite reads a submitted SOC 2 report the same way it reads any other compliance document, mapping its findings against NIST, ISO 27001, HIPAA, and PCI DSS so a risk team sees the full compliance picture instead of one document in isolation. Reconciling a SOC 2 report against everything else a vendor has submitted by hand doesn't scale past a handful of vendors, which is why that mapping runs as part of a broader vendor risk assessment program rather than a one-time document review. Insurance carriers underwriting cyber policies are increasingly asking for this kind of continuously reconciled view instead of a static report on file.

See also: A Risk-Based Approach to TPRM