Case Study

From Zero to SOC 2 Type II: Building Compliance at a Security Startup

Jacob Masse, Head of Operations at Humera, Inc.

When I joined Humera as Head of Operations, the company had a strong product and a growing customer base. What it did not have was a compliance program. No SOC 2 report. No formal security policies. No documented controls. For a company selling passive human-verification and anti-bot detection to enterprise clients, that gap was becoming a dealbreaker.

This is the story of how we went from zero compliance infrastructure to a full SOC 2 Type II attestation across 76 controls, while keeping a platform processing millions of requests per day running at 99.9% uptime with sub-100ms latency. It took planning, a team of 15, and a willingness to rethink how we worked.

76 Controls Established
60+ Assets Audited
15 Team Members
99.9% Uptime Maintained

Why SOC 2 Mattered for Humera

Humera's platform sits between end users and our customers' applications. Every page load, every form submission, every API call passes through our verification layer. Enterprise buyers do not hand that kind of access to a vendor without proof that the vendor takes security seriously. SOC 2 Type II is that proof.

We were losing deals. Procurement teams asked for our SOC 2 report, and we had to say we were working on it. Some prospects waited. Others did not. The business case was clear: compliance was not optional, it was a revenue requirement.

The Starting Point

I started by mapping what we had. The honest answer was: less than I expected, but more than nothing. Our engineering team had solid development practices. Code reviews happened consistently. Infrastructure was well-architected. But none of it was documented in a way that an auditor could evaluate.

The first step was a company-wide security audit. I cataloged every asset we owned or operated: 60+ items including production domains, staging environments, cloud servers, API keys, third-party SaaS integrations, DNS records, SSL certificates, and internal tools. For each asset, I documented the owner, the access level, the last review date, and the risk classification.

The audit alone took three weeks. Most companies underestimate this step. You cannot secure what you have not inventoried, and you cannot pass an audit for controls you have not documented.

Designing the Control Framework

SOC 2 Type II covers five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. We scoped our audit to security and availability, which aligned with what our customers cared about most. That gave us 76 individual controls to define, implement, and evidence.

I broke the work into four domains:

The 5-Layer PR Approval Flow

This was one of the more involved controls, and it became a model for how we approached everything else. The flow works like this:

  1. Automated checks. Every pull request triggers CI/CD pipelines that run unit tests, integration tests, linting, and static analysis. If any check fails, the PR cannot proceed.
  2. Peer review. At least one team member with domain knowledge reviews the code for logic errors, edge cases, and maintainability.
  3. Security review. For changes touching authentication, authorization, data handling, or external APIs, a security-focused reviewer evaluates the diff for vulnerabilities.
  4. Lead approval. A team lead or senior engineer signs off on the change from an architectural perspective, confirming it aligns with system design standards.
  5. Deployment gate. The final merge triggers a staged rollout with automated health checks. If error rates spike or latency degrades, the deployment rolls back automatically.

This sounds heavy. In practice, most PRs move through the full pipeline in under four hours. Small, well-scoped changes move faster. The key is that every step produces an artifact the auditor can reference: a test report, a review comment, an approval timestamp, a deployment log.

The Hard Part: Doing This Without Breaking Production

Humera's platform processes millions of verification requests daily. Our customers embed our SDK into their applications, and if our service slows down or goes offline, their users cannot complete actions on their sites. Sub-100ms response times are not a goal, they are a contractual expectation.

Introducing new controls into an environment like that requires care. Every new approval step in the deployment pipeline adds latency to the release cycle. Every new access restriction risks locking an engineer out during an incident. Every new monitoring rule generates alerts that someone has to triage.

We handled this by rolling out controls in phases. We started with the controls that carried the lowest operational risk: documentation policies, access reviews, vendor assessments. Then we moved to change management controls, testing them on non-critical repositories first. Production deployment controls came last, after we had validated the workflow on lower-stakes systems.

Throughout the process, I tracked two numbers obsessively: platform uptime and mean time to deploy. Uptime stayed at 99.9%. Mean deployment time increased by 40 minutes on average, which we accepted as a reasonable cost for the level of assurance it provided.

Directing the Team

I directed a team of 15 people through this process. That included engineers across backend, frontend, and infrastructure. None of them had compliance as their primary job. Everyone had product work to ship.

The approach that worked was embedding compliance into existing workflows rather than creating parallel ones. Engineers did not fill out compliance spreadsheets. Instead, we configured their existing tools to generate the evidence automatically. GitHub produced audit logs. Our CI system produced test reports. Our infrastructure-as-code setup produced configuration snapshots. My job was to connect those artifacts to the controls they evidenced.

I held weekly 30-minute syncs with control owners to review evidence gaps and upcoming deadlines. These meetings were short and specific: here is what the auditor needs, here is what we have, here is what is missing. No presentations. No status reports for the sake of status reports.

Securing Cloud Infrastructure Partnerships

While the compliance program was underway, I also negotiated and secured over $200K in cloud infrastructure partnerships with Google Cloud, AWS, Microsoft Azure, DigitalOcean, and Cloudflare. These partnerships were not just about cost savings. They gave us access to enterprise support tiers, dedicated account teams, and infrastructure credits that let us build redundancy without blowing the budget.

The SOC 2 work helped here. When you can show a cloud provider that you run a mature security program with documented controls and audit evidence, they take you more seriously. Compliance opens doors that cold emails cannot.

The Audit

When the auditors arrived, we were ready. Every control had documented evidence. Every policy had an owner and a review date. Every system had an access log and a configuration baseline.

The Type II observation period ran for several months. During that window, the auditors sampled our controls at multiple points to verify they were operating consistently, not just designed well on paper. We passed with no exceptions.

What I Would Tell Other Startups

If you are approaching SOC 2 for the first time, here is what I learned:

Results

Humera achieved SOC 2 Type II compliance across 76 controls with zero exceptions. The platform maintained 99.9% uptime and sub-100ms latency throughout the entire process. We unblocked enterprise deals that had been stalled on compliance requirements. And we built a security program that scales with the company rather than requiring a full rebuild at the next audit cycle.

Compliance is not glamorous work. It does not make for exciting demos or viral launch posts. But for a company whose product sits in the critical path of its customers' applications, it is the foundation everything else depends on. We built that foundation, and we did it without slowing down.