Every cloud VMS, monitoring platform, and hosted access control vendor will eventually hand you the phrase “we’re SOC 2 compliant.” SOC 2 is genuinely useful evidence, but only if you know what it is: an attestation report, written by an auditor, about controls the vendor itself defined. Reading one properly is a due-diligence skill, and the security trade needs it both as buyers and, increasingly, as the service providers being asked.
What a SOC 2 report is
SOC 2 comes from the AICPA’s attestation framework. An independent CPA firm examines the service organization’s controls against the Trust Services Criteria: Security (mandatory), plus optionally Availability, Processing Integrity, Confidentiality, and Privacy. The output is not a certificate; it is a detailed report describing the system, the controls, the auditor’s tests, and the results. That structure is its strength: unlike a logo, a report can be read, and the interesting parts are always in the details.
Type I versus Type II
A Type I report says the controls were suitably designed and in place on one date. A Type II report says they operated effectively over a period, typically six to twelve months, with the auditor testing them through that window. Type II is the meaningful one. A vendor offering only a Type I is telling you their program is young; reasonable for a startup, worth an explicit conversation for anything holding your video or credentials.
How to actually read one
Four stops. Scope: which services and locations are covered, and is the product you are buying actually in it. Criteria: Security alone, or also Availability and Confidentiality, which matter for monitoring and video retention promises. Exceptions: the auditor’s test results list controls that failed testing; a handful with sensible management responses is normal, a pattern in access management or change control is a finding about culture. And the carve-outs: subservice organizations (the cloud provider underneath, the monitoring centre subcontractor) are often excluded from scope with their controls assumed, which tells you where the vendor’s attestation actually stops. Reports are confidential and shared under NDA, so a vendor who will not share one under NDA has answered your question a different way.
For Canadian security companies on the other side
MSSPs, central stations, and hosted-platform providers selling to enterprise will meet SOC 2 demands sooner rather than later. The honest sequencing mirrors ISO 27001: build real practices first, then attest. The two overlap heavily, and firms often pursue 27001 certification and SOC 2 reporting off the same control set; which one leads is usually decided by whether your customers are procurement departments (27001’s certificate travels well) or US-style vendor risk teams (SOC 2 reports are the currency).
How it fits
SOC 2 answers “did an auditor verify this vendor’s controls operated?” It complements rather than replaces your own diligence: a clean Type II on a platform still deployed with default passwords is a deployment problem, not a paperwork gap.
Related guides
- ISO/IEC 27001: ISO/IEC 27001: Information Security Management
- NIST CSF 2.0: NIST Cybersecurity Framework 2.0
References
Last updated 2026-07-24.