Enterprise Security: Our Journey to SOC 2 Type II Compliance
An inside look at achieving SOC 2 Type II with zero findings — what the certification actually proves, why voice data raises the bar, the architecture decisions behind it, and how to evaluate any vendor's security claims.
David Kim
VP of Security
VM Hunter completed our SOC 2 Type II audit with zero findings. That sentence is the kind of thing companies put in a press release and move on from, but it is worth unpacking — because most people evaluating a vendor's security posture are not entirely sure what SOC 2 proves, what it does not, and which questions actually distinguish a serious security program from a well-marketed one.
This is an honest account of what we built, why we made the architectural choices we did, what the audit process actually involved, and — in the final section — how to interrogate any vendor's security claims, including ours.
What SOC 2 Type II Actually Is
SOC 2 is an auditing framework developed by the American Institute of Certified Public Accountants. It is not a checklist you pass or a certification a regulator issues. It is an independent auditor's opinion on whether the controls you claim to have are designed appropriately and are actually working.
The distinction between the two report types is the part most people miss, and it matters enormously.
Type I is a point-in-time assessment. An auditor examines your controls on a specific date and confirms they are designed appropriately. It answers: do the right controls exist right now?
Type II examines the operating effectiveness of those controls over an extended observation window — typically six to twelve months. The auditor does not just confirm a control exists; they sample evidence across the entire period to verify it operated continuously. It answers: did the controls actually work, consistently, for a year?
Type I is a photograph. Type II is a documentary. A company can achieve Type I by implementing controls the month before the audit. Type II requires that the controls were genuinely part of how the company operated throughout the window, which is a substantially harder thing to fake.
Our audit covered a twelve-month observation window. When evaluating any vendor, ask which type they hold and what the window was. "SOC 2 compliant" in marketing copy frequently means Type I, and occasionally means "we have started the process."
What "Zero Findings" Means — and Does Not
Zero findings means the auditor identified no exceptions: no instance where a control we claimed failed to operate as described during the observation period.
It is a genuinely good outcome. It is also worth being clear about what it is not. It is not a statement that our software is free of vulnerabilities, that we cannot be breached, or that our security is superior to a company with one minor finding. SOC 2 evaluates whether you do what you say you do. A company with narrow, modest controls can achieve zero findings more easily than a company with an ambitious control set and one documentation gap.
This is why the scope of the audit matters as much as the outcome, and why you should ask to see the report rather than the badge.
The Five Trust Services Criteria
SOC 2 is organized around five criteria. Only the first is mandatory, and vendors choose which of the remaining four to include in scope. That choice tells you a lot.
Security (required) — protection against unauthorized access, covering access control, encryption, network security, and change management.
Availability — the system is accessible as committed. Relevant to anything with an uptime SLA.
Processing Integrity — processing is complete, valid, accurate, and timely. Directly relevant to a classification service: are we returning correct results, and can we demonstrate it?
Confidentiality — information designated confidential is protected throughout its lifecycle.
Privacy — personal information is collected, used, retained, and disclosed in conformity with commitments.
Our audit covered all five. Many vendors scope only Security, which is legitimate but much narrower. If a vendor processes personal data and their SOC 2 excludes Privacy and Confidentiality, that is a reasonable question to raise.
Why Voice Data Raises the Bar
Most SaaS companies handle structured data: names, emails, transaction records. Voice is categorically different, and the difference drove most of our architectural decisions.
Audio is unbounded personal data. A database field labelled "phone number" contains a phone number. A three-second audio clip of someone answering their phone may contain their name, their employer, a medical detail, a family member speaking in the background, or their voice biometric — which in several jurisdictions is regulated as sensitive biometric data with its own consent requirements.
You cannot know in advance what is in an audio buffer. That means you cannot apply field-level classification the way you would to structured data, and you have to treat the entire stream as sensitive by default.
Biometric law applies. Illinois' BIPA, Texas' CUBI, and comparable statutes in other jurisdictions create specific obligations around voiceprints, with meaningful private rights of action. Any system that processes voice at scale has to be designed with the assumption that voice data may be treated as biometric.
Real-time processing forecloses easy answers. A batch system can encrypt data at rest and analyze it later at leisure. We classify audio in under 50 milliseconds while a call is live, which means audio is in memory, in transit, and being processed continuously — the states where data is hardest to protect.
This combination led to the single most consequential decision in our architecture.
We Do Not Retain Call Audio
By default, VM Hunter does not store customer call audio. Audio enters the classification pipeline, is analyzed in memory, and the buffer is discarded when the classification is returned. What persists is the classification result and metadata — not the recording.
The reasoning is straightforward: the most reliable way to protect data is not to hold it. Retained audio is a liability that grows over time. It expands breach impact, complicates data subject access and deletion requests, creates cross-border transfer obligations, and makes you a more attractive target.
This was not a costless choice. Retained audio would make model improvement considerably easier — it is the obvious training corpus. We chose instead to build our training pipeline on explicitly consented data with separate contractual arrangements and separate infrastructure, entirely isolated from production customer traffic. Customers who want to contribute data to model improvement opt in deliberately; it is never the default, and it is never a condition of service.
For customers who require retention for their own quality assurance or regulatory purposes, it is available as an explicit configuration with a customer-defined retention period and region pinning. It is off unless you turn it on.
The Architecture Behind the Controls
Controls on paper are worthless without architecture that enforces them. The relevant pieces:
Encryption
All data in transit uses TLS 1.3. Media streams over WebSocket are encrypted end to end. Data at rest uses AES-256 with keys managed in a dedicated key management service, rotated on a defined schedule. Keys are never stored alongside the data they protect.
Tenant Isolation
Multi-tenancy is where SaaS security most often quietly fails. Isolation enforced only in application logic means one missing WHERE clause is a cross-tenant data exposure.
We enforce isolation at the data layer, not just the application layer, so that a query which omits the tenant scope fails rather than returning another customer's records. Every query path that touches customer data is scoped by tenant identity derived from the authenticated session, never from a client-supplied parameter. Client-supplied tenant identifiers are the classic vector for horizontal privilege escalation, and they are not trusted anywhere in our stack.
Least Privilege and Access Control
No standing production access. Engineers do not have persistent credentials to production systems. Access is requested, time-boxed, approved, and logged, and it expires automatically.
Multi-factor authentication is mandatory for all internal systems with no exceptions, including for executives — a carve-out we see surprisingly often and which defeats the purpose entirely.
Access reviews run quarterly. Every account, every permission, reviewed and either justified or revoked. Deprovisioning on employee departure is automated rather than dependent on someone remembering a checklist.
Logging and Monitoring
Every access to customer data is logged immutably. Logs are written to append-only storage that operational credentials cannot alter, which is what makes them useful during an incident investigation — a log an attacker can edit is not evidence.
Anomaly detection alerts on unusual access patterns: volume outside normal ranges, access at unusual hours, queries spanning unusual numbers of tenants.
Change Management
All production changes go through code review, automated testing, and a documented approval path. Infrastructure is defined as code, so infrastructure changes are reviewable and auditable in the same way application changes are. Every deployment is traceable to a specific commit, a specific reviewer, and a specific approval.
Vulnerability Management
Dependency scanning runs continuously in CI. Static analysis runs on every pull request. Third-party penetration testing runs annually with remediation tracked to closure, and we maintain a bug bounty program because external researchers reliably find things internal teams do not.
What the Audit Process Actually Involved
For anyone about to undertake this, an honest description is more useful than a triumphant one.
Readiness assessment. Before the observation window opens, you map your existing controls against the criteria and find the gaps. This was humbling. We had strong technical controls and considerably weaker documentation. Several things we genuinely did consistently were not written down anywhere, and an auditor cannot accept "we always do this" as evidence.
Remediation. Closing gaps. Some were technical, but the majority were policy and process: formal incident response runbooks, a documented risk assessment methodology, a vendor management program, security awareness training with completion tracking.
The observation window. Twelve months of operating the controls while collecting evidence continuously. This is the part that cannot be compressed. It is also where most of the real work happens, because sustaining a control for twelve months is a genuinely different discipline from implementing it once.
Evidence collection. Access review records, change approvals, training completions, incident tickets, scan results, alert investigations. We automated collection through Vanta early, which was the single highest-leverage decision in the whole project. Manual evidence collection across a twelve-month window is enormously labor-intensive and error-prone.
Fieldwork. The auditor samples across the period, interviews personnel, and tests controls directly. They do not accept assertions. If you claim quarterly access reviews, they want the records for all four quarters, and they will pick specific accounts and trace them.
The Honest Lesson
The hardest part was not implementing security controls. It was building the discipline to operate them consistently and evidence them continuously for a year. Most engineering organizations have decent instincts about security. Far fewer have the operational rigor to demonstrate those instincts were applied on a specific Tuesday in March.
Continuous Compliance
SOC 2 is not a finish line. The certification covers a past window, and it expires.
Automated monitoring. Vanta continuously monitors our posture with real-time alerts on policy drift, automated evidence collection, training tracking, and vendor risk management.
Testing cadence. Quarterly: vulnerability scans and access reviews. Annually: third-party penetration testing and disaster recovery exercises. Ongoing: bug bounty, dependency scanning, and security code review on every change.
Incident response drills. We run tabletop exercises against realistic scenarios. An incident response plan that has never been exercised is a document, not a capability.
What This Means If You Are the Customer
Practically, our SOC 2 Type II report gives you four things:
Independent validation. A third party with professional accountability tested our controls rather than accepting our description of them.
Faster procurement. Most enterprise security reviews accept a SOC 2 Type II report in place of a bespoke questionnaire, which typically removes weeks from a security review cycle.
Evidence for your own audit. If you are subject to SOC 2, ISO 27001, or similar, your auditors will ask about your vendors. Our report is evidence for your program.
A concrete baseline. Not a marketing claim about taking security seriously, but a documented, tested set of controls you can read.
Enterprise customers can request the full report under NDA. We recommend actually reading it rather than filing the badge.
How to Evaluate Any Vendor's Security Claims
This is the section worth keeping regardless of which vendor you choose. Most security reviews ask the wrong questions — the ones a vendor can answer with a yes.
Ask for the report, not the badge. A logo on a website is not evidence. Request the report under NDA and read the scope section, the observation window, and any exceptions. A vendor unwilling to share it is telling you something.
Check the type and window. Type I or Type II? How long was the observation window? A three-month Type II window is much weaker than twelve.
Check which criteria are in scope. Security only, or all five? If they process personal data without Confidentiality and Privacy in scope, ask why.
Ask what happens to your data by default. Not what is possible — what is the default. Is audio retained? For how long? Where geographically? Is it used for model training, and is that opt-in or opt-out? Opt-out training on customer data is common and frequently buried in terms.
Ask specifically about subprocessors. Their security posture is now part of yours. Ask for the list and how they are assessed. A vendor with excellent controls routing your audio through an unassessed third-party ASR provider has a gap they may not have volunteered.
Ask how tenant isolation is enforced. The answer you want describes enforcement at the data layer. "We filter by customer ID in the application" is a single-bug-away architecture.
Ask about standing production access. How many engineers can access production customer data right now, without approval? The best answer is zero with time-boxed elevation.
Ask about incident notification. What is the contractual timeline for notifying you of a breach affecting your data? Get a number, in the contract.
Ask when the last penetration test was and whether findings were remediated. A test with unremediated findings is worse than no test, because it documents known unaddressed risk.
Ask about the exit path. How do you get your data out, in what format, and what is the deletion process and timeline when you leave? Data portability is a security question — a vendor you cannot leave is a vendor you cannot hold accountable.
Looking Ahead
Security work does not end. Our roadmap:
- HIPAA compliance for healthcare customers (Q2 2026)
- ISO 27001 certification (Q3 2026)
- FedRAMP authorization for government customers (2027)
Each expands the set of regulated environments we can operate in, and each requires the same underlying discipline: controls that genuinely operate, evidenced continuously.
Conclusion
The most important decision in our security program was not a control we implemented — it was choosing not to retain call audio by default. Every other control protects data we hold; that decision reduces what we hold at all, and it shrinks the blast radius of every conceivable failure. It cost us the easiest possible path to training data, and it was still the right call.
SOC 2 Type II with zero findings across all five Trust Services Criteria validates that our controls operated as described for twelve continuous months. It is meaningful precisely because it is about sustained operation rather than a point-in-time snapshot.
But do not evaluate us on the badge. Read the report, ask the questions in the section above, and hold every vendor in your stack — including this one — to answers that are specific rather than reassuring.
Questions about our security practices? Reach out to security@vmhunter.com, or start a free trial with 5,000 calls per month, no credit card required.