The question procurement always asks

Somewhere in every serious vendor review, a security or procurement reviewer types the same five words into an email: "Are they SOC 2 compliant?" It feels like a clean yes/no gate — a box that is either ticked or isn't. It is not. "SOC 2 compliant" is not really a status a company can hold, and treating a report as a magic pass (or its absence as an automatic fail) is how teams both over-trust a certified vendor and wrongly rule out a secure one.

This is a plain-English map of what a SOC 2 report is, what it covers, what it deliberately does not, and — the part that actually matters when you are choosing where to send your signed contracts — the concrete security controls you can verify for yourself. It is general guidance, not legal or audit advice.

What SOC 2 actually is

SOC 2 is not a certification a regulator issues. It is an attestation report produced by an independent CPA firm under the AICPA's standards. The auditor examines a service organization's controls against the Trust Services Criteria and writes an opinion on whether those controls are suitably designed — and, for one of the two report types, whether they actually operated over a period of time.

Two distinctions decide what a report is worth to you:

  • Type I vs. Type II. A Type I report describes the controls and opines that they are designed appropriately at a single point in time. A Type II report goes further and tests whether those controls operated effectively over a review window — typically 3 to 12 months. Type II is the one that means something, because "we designed a good control" and "the control actually ran every day for a year" are very different claims. If a vendor waves a SOC 2 report, ask which type and what the review period was.
  • Scope. A SOC 2 report covers a defined system boundary and a chosen set of criteria — not automatically the whole company or the specific product you are buying. A report scoped to a different platform, or to only the Security criterion, may not say much about the tool you actually plan to use.

Because a SOC 2 report contains the auditor's findings and often the vendor's system description, it is usually shared under NDA rather than published. "We have SOC 2" with nothing behind it is marketing; the report — its type, period, scope, and any noted exceptions — is the substance.

The five Trust Services Criteria — and which matter for signing

SOC 2 is built on five criteria. A vendor picks which ones their report covers:

  1. Security (the only mandatory one) — protection against unauthorized access, covering access controls, encryption, monitoring, and change management.
  2. Availability — that the system is up and reachable as committed.
  3. Processing Integrity — that processing is complete, valid, accurate, and authorized.
  4. Confidentiality — that information designated confidential is protected.
  5. Privacy — that personal information is collected, used, retained, and disposed of per the vendor's notice.

For an e-signature platform, Security and Confidentiality carry the most weight — your executed agreements and their signer data are exactly the confidential information those criteria are about. Processing Integrity maps unusually well to signing, too: the whole promise of a signed record is that it is complete and unaltered, which is precisely what a tamper-evident audit trail demonstrates. If a vendor's report covers only Security, that is a fine floor — but notice what it leaves unexamined.

What SOC 2 does not tell you

A report is a useful signal, not a guarantee, and it is important to know its edges:

  • It is historical. A Type II covers a past window. Controls can lapse the day after the period closes; the report cannot see forward.
  • It is not legal validity. SOC 2 says nothing about whether a signature is enforceable — that is ESIGN, UETA, and eIDAS territory, an entirely separate question from how the vendor secures its systems.
  • It is not HIPAA, GDPR, or PCI. Each has its own requirements. A SOC 2 report can support a HIPAA or GDPR position, but it does not replace a BAA or a DPA.
  • A clean opinion can still list exceptions. Read the testing results, not just the cover letter.

The controls you can verify yourself

Here is the reframe that makes a vendor review sharper: SOC 2 is evidence that controls exist, but for an e-signature tool many of the controls that matter are ones you can inspect directly, report or no report. When you evaluate a signing platform — the broader exercise in choosing an e-signature platform and running a defensible process in a regulated industry — look for the concrete mechanisms behind each criterion:

  • Encryption, in transit and at rest. Documents and signer data should be encrypted on the wire and in storage. This is the baseline the Security and Confidentiality criteria both assume.
  • Document integrity you can check independently. Every document sent through Hitt Hosting Sign is sealed with a SHA-256 hash and an RFC 3161 trusted timestamp, and every step — sent, viewed, signed — is written to a tamper-evident audit chain that yields a portable evidence certificate. That is Processing Integrity you can verify on a single document, not take on faith from an annual report.
  • Access control and least privilege. Look for real roles and permissions, scoped rather than all-or-nothing API keys, and two-factor authentication on accounts — the day-to-day substance of the Security criterion.
  • An account-level audit log. A record of sign-ins, 2FA changes, and API-key lifecycle events is monitoring you can actually read, and it is the evidence a SOC 2 examiner would look for internally.
  • Data residency and retention you control. Where your signed documents physically live and how long they are kept before deletion speak to Confidentiality and Privacy — and they are questions with concrete, checkable answers.

None of that is a substitute for an independent auditor's opinion where your policy requires one. But it does mean you are never limited to a single yes/no question. You can examine the security posture itself.

How to run the review well

  • Ask for the report, then read past the cover. Get the type, the review period, the scope boundary, and the exceptions — not just confirmation that one exists.
  • Match the criteria to your risk. For signing, weight Security, Confidentiality, and Processing Integrity most.
  • Do not let a report end the inquiry. Verify encryption, integrity proof, access controls, audit logging, residency, and retention directly — they are the controls doing the work every day.
  • Keep the legal question separate. SOC 2 is about how the vendor is run; enforceability is about whether the signature holds up. You need both answered, from different sources.

The takeaway

SOC 2 is a valuable signal — an independent look at whether a vendor's controls are designed and, in a Type II, actually operating. But it is a report about a company over a past window, not a certificate of trustworthiness, and it says nothing about whether your signatures are legally valid. Treat it as one input. Then do the thing a report can't do for you: verify the concrete controls — encryption, an independently checkable audit trail, scoped access, real audit logging, and data you control — that determine whether your signed records are actually safe. If you want to walk through exactly how Hitt Hosting Sign handles each of those, see the security model or contact us with your reviewer's questions.

This article is general guidance on security assurance and e-signatures, not legal, audit, or compliance advice. SOC 2 scope and your own obligations are specific to your situation; confirm requirements with your security, compliance, and legal advisers.