Canonical Technical Definition

An independent auditing framework developed by the AICPA that evaluates an organization's controls governing security, availability, processing integrity, confidentiality, and privacy.

SOC 2 (System and Organization Controls 2) is an internationally recognized auditing procedure developed by the American Institute of Certified Public Accountants (AICPA). It evaluates how technology companies protect customer data across five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

For enterprise procurement teams, requiring a SOC 2 Type II report is standard operating procedure when evaluating cloud software. When an enterprise sends private meeting audio and strategic notes to a cloud SaaS provider, the enterprise inherits all of that provider’s operational vulnerabilities.

The five Trust Services Criteria in SOC 2

  1. Security: The system is protected against unauthorized access, data exfiltration, and cyberattacks through firewalls, multi-factor authentication, and intrusion detection.
  2. Confidentiality: Information designated as confidential is protected through encryption in transit and at rest, access controls, and strict employee NDAs.
  3. Privacy: Personal information is collected, used, retained, disclosed, and disposed of in accordance with the vendor’s published privacy notice.
  4. Processing Integrity: System processing is complete, valid, accurate, timely, and authorized (ensuring calculations and data transformations do not introduce silent errors).
  5. Availability: The system is operational and accessible for use as committed or agreed in service level agreements (SLAs).

The limitations of SOC 2 for cloud AI note tools

While valuable, SOC 2 reports have inherent limitations that enterprises frequently misunderstand:

  • Point-in-time vs continuous: A Type II report evaluates historical compliance; it cannot prevent a future zero-day breach, insider threat, or rogue employee access event.
  • Third-party sub-processors: Most cloud AI note tools rely on sub-processors (like OpenAI, AWS, or Azure). The vendor’s SOC 2 report only covers their own infrastructure, not the third-party models processing your audio.
  • Law enforcement subpoenas: An audited cloud vendor is legally obligated to comply with secret court orders and subpoenas, decrypting customer records without user notification.

The local-first architectural alternative

Local-first software like Oyma redefines enterprise compliance by eliminating the cloud vendor attack surface entirely:

Cloud SaaS Vendor Procurement:
[Enterprise Legal] ──(Review 80-page SOC 2 Report)──> [Vendor Cloud Security Risk]
                                                               │
[Mandatory DPA] <──(Security Questionnaires)───────────────────┘

Local-First Procurement (Oyma):
[Enterprise Mac] ──(Local Execution Only)──> [Zero Cloud Ingestion / Zero Vendor Risk]

Because Oyma processes meeting audio on-device and stores Markdown notes on local employee Mac drives, no corporate data enters a third-party multi-tenant cloud. Compliance reviews take minutes instead of months.

Frequently asked questions about SOC 2 Type II Security Standard

What is the difference between SOC 2 Type I and Type II?

A Type I audit assesses whether security controls are properly designed at a single point in time. A Type II audit evaluates whether those controls operated effectively over an extended period (typically 6 to 12 months).

Does a vendor's SOC 2 compliance guarantee my notes are private?

No. SOC 2 merely certifies that the vendor follows their own documented operational procedures. If a vendor's policy states that employees may review meeting transcripts for QA, SOC 2 verifies that process—it does not prevent it.

Why does local-first software simplify enterprise security compliance?

Local-first applications store no customer data on vendor servers. Enterprise security teams do not need to review vendor SOC 2 reports because no enterprise data ever crosses the vendor's perimeter.