SOC2 Type II Certification: One Year of Writing Policies and Proving We Follow Them

We received our SOC 2 Type II certification from Sensiba with a clean audit opinion and no noted exceptions. Here's what we learned building a compliance program from scratch.

Summary: What SOC2 Actually Requires

• SOC2 is about people, processes, and risks, not just technology.
• Type I means you document what you do. Type II means you prove you actually do it over months.
• We used Drata for automation and Sensiba for auditing.
• It covers technical, physical, and administrative security controls.
• It took us one year to achieve Type II compliance.
• Start when customers demand it. It's a commitment of time, money, and organizational alignment.

We were already SOC2 Type I compliant. Type II proves we followed our documented processes over an extended observation period.

This article covers the practical lessons, not the SOC2 framework itself.

Why We Started: Customer Security Questionnaires Were Killing Us

Several team members had SOC2 experience from previous companies. We were also drowning in massive Excel files from customers asking about security practices, SDLC, backups, vulnerabilities, and disaster recovery plans. SOC2 answers all these questions at once.

We were doing many things right but lacked consistent documentation. As a B2B company, SOC2 accelerates sales cycles and builds customer trust. It also creates a foundation for business growth.

Concrete Changes to Daily Operations

Here's what we documented and now enforce:

• All laptops: encrypted, automatic updates, screen lock, password protection after inactivity.
• Mandatory security awareness training for all employees.
• Company-wide Code of Conduct acceptance.
• 1Password for organization-wide password management (no more Chrome password manager).
• SSO, MFA, and RBAC on everything possible. Least privilege principle everywhere.
• Clear incident response procedures with resolution tracking.
• GitHub PRs require 2 reviewers, protected main branches, CODEOWNERS defined.
• Teleport for internal infrastructure access.
• Automated security scans for static code analysis and dependency vulnerabilities.
• Regular vendor security reviews.
• Regular penetration testing.

Our SOC 2 Type I/Type II reports contain full details. Contact us to request them. Both existing and prospective customers must sign an NDA (that's a SOC2 requirement).

Timeline: One Full Year

We started in November 2022 by joining Drata. We had no hard deadline, so we took time to learn and do it right. We were also a small team doing this alongside regular work.

Drata automates compliance by integrating with existing tools. Our first call with them was direct and transparent, no sales pitch. Thanks to Italo for the positive first impression.

This article is not sponsored by Drata. We also evaluated Vanta but preferred Drata's approach and pricing. Compleye looks competitive now too.

Cost Breakdown

Compliance automation platform pricing depends on:

• Employee count: everyone needs a monitoring agent on their laptop.
• Compliance frameworks: SOC2, ISO27001, HIPAA, etc.

Auditor fees are separate. Sensiba in the Bay Area was professional, helpful, and efficient (even responding at the end of December).

The hidden cost is team time. HR, Finance, Engineering, and Founders all spend hours discussing policies, writing them, reviewing them, and implementing them. Engineers assess infrastructure, secrets management, vulnerability detection, and more. Auditors ask many questions and need evidence. Estimate conservatively.

Screenshots as Compliance Evidence

When automation doesn't cover everything, you take screenshots. Similar to fly.io's experience, screenshots are the hidden cornerstone of SOC2 compliance. They prove to auditors that you do what you document.

Screenshots work for audit logs, dashboards, Trello boards, anything that proves controls are implemented but isn't accessible via API.

Without automation, prepare to extract JSON from cloud providers and capture screenshots from every SaaS tool you use.

Writing 20+ Policies

Writing internal policies consumed the most time at the start. We documented everything from hiring processes to security policies. Every document needed to be thorough, clear, and consistent.

Compliance platforms provide templates as starting points. They help you get from zero to one. Version control for each modification is mandatory.

This required effort from many people and VPs. We now have comprehensive policies for onboarding new employees and partners. The process revealed areas for improvement.

All employees must review and sign policies regularly.

Legal note: even as a US company, we have employees in France. French employment law requires legal documents in French when they bind employee responsibilities.

Laptop Monitoring Agents

Engineers hate installing monitoring agents. Concerns about performance and privacy are natural.

The agent just polls the OS regularly for system metrics related to SOC2 controls. It's exactly like osquery.io.

We used agents for laptops, not infrastructure (where we use cloud solutions). When a laptop falls out of compliance (screenlock not configured, etc.), we get an alert.

We had to explain to engineers why this mattered, how it protects them, and that the agent is non-intrusive. Contractors with their own laptops required separate handling, which SOC2 allows if you can justify it.

Related tooling we adopted:

• 1Password: centralized password management, MFA, team vaults, SCIM provisioning via Google Workspace integration.
• Clear org charts via BambooHR, integrated with Google for account provisioning.
• Checkr for background checks in the USA. Background checks in Europe are restricted or illegal, something to push back on if auditors ask.

Compliance is about people, not just systems. Employees own the company's security. Giving them tools and knowledge makes everyone more aware and responsible.

Penetration Testing: Required If You're Serious

Pentesting is optional for SOC2 but highly recommended. It identifies security vulnerabilities, limits data breaches, and tests both external and internal threat scenarios.

Three flavors:

• White Box: Full access to internals. Insider perspective.
• Gray Box: Limited information. Mix of insider and outsider testing.
• Black Box: No prior knowledge. Simulates external attacker.

Pentesting isn't just about external hackers. It also tests whether insiders could escalate privileges or cause damage.

A pentester (a human, not just a tool) needs to understand your product: architecture, use cases, critical components (RBAC, tokens, URLs, encryption, SQL), and critical data. You run pentesting every 6 months because your product and its vulnerabilities evolve.

Large customers ran their own pentests on our products and found only minor issues. We also engaged an official third-party pentester for SOC2 compliance. They found minor vulnerabilities like visible tokens in UI, URL parameters leaking info, JWT issues, HTTP header problems, and OWASP items.

From a black box testing report:

During the audit, many good practices have been observed. The auditors rate the application's level of security as high. The Console product and Gateway product have a lot of good practices in terms of security development. The security level of the application is above the average of other audits previously performed on different clients.

Thanks to our engineering team. Security is everyone's responsibility, frontend to backend.

Pentesting Cost and Scope

Pentesting takes 1 to N weeks depending on product size. Expect back and forth with the pentester, so the team must be available. Critical vulnerabilities are reported immediately for fast fixes. The final report includes all vulnerabilities, severity ratings, and recommendations.

Defining scope upfront is hard because you want "everything" tested (impossible). After the first audit, work with the pentester to narrow scope for subsequent tests.

We avoided vendors requiring ultra-specific details (API route counts, frontend screen counts, IP counts) for pricing. A pentester is a human you interact with. Flexibility matters.

We don't just do HTTP APIs. We manage critical aspects through the Kafka protocol with encryption, masking, authentication, authorization, and RBAC. Finding a pentester with Kafka knowledge was valuable.

SOC2 Is a Marathon

Initial timelines were optimistic. We started with OKR-style goals ("X policies per month") and missed them. Early productivity spiked as everyone explored the shiny new compliance platform. Then day jobs took over.

Policies take time to write, review, and implement. Writing two dozen policies requires team review to ensure clarity. You review others' policies, they review yours. It's a valuable learning exercise but can become endless. You must timebox.

Infrastructure controls need building and deploying. Synchronization issues arise. You need more monitoring. You need system integrations to remove humans from the loop. You need weekly control validity checks. SOC2 becomes part of daily work, not a special project.

Third-Party Vendor Management

A typical SaaS company uses 50-100 other SaaS tools. Managing third parties requires clarity:

• Are they critical? What's the impact if they fail?
• Do they protect our data? What data do they have? Who has access? Do they provide audit mechanisms?
• What happens to accounts and access when someone leaves?

Re-evaluate these questions yearly as you add systems.

We reviewed vendors' security policies, SLAs, and security awareness protocols. If they lack SOC2 certification, you hope they have documentation about security practices. As a last resort, call them. You need evidence.

GitHub, Segment, Mixpanel, Sentry, Hubspot, Bamboo, Auth0, Checkly, Datadog, Algolia, Linear: all SOC2 compliant.

CVE Management: Constant Vigilance

Vulnerability management never stops. I frequently reminded teams to keep dependencies updated and free of vulnerabilities. One vulnerability can compromise the entire system.

CVEs (Common Vulnerabilities and Exposures) are categorized as critical, high, or medium/low based on severity and impact. Existing dependencies can develop new vulnerabilities from updates. Vulnerability scanners aren't perfect. We encountered false positives requiring investigation and customer explanations (see Grype's false positive issues).

Prevent vulnerabilities from being added rather than reacting after merge. We use:

• GitHub Dependabot
• Snyk
• Docker Scout
• Harbor
• Grype

We built a custom GitHub bot called Grumpy that alerts when a PR introduces a dependency with a vulnerability. Why so many tools? They don't find the same vulnerabilities, and customers use their own tools too.

Critical vulnerabilities require immediate resolution. Contracts often legally bind you to fix them promptly. Ignoring them loses customer trust.

We made significant progress. Engineers are fully aware and vulnerability management is normal work. Old reports showed 50 vulnerabilities including 5 critical and many high. Today: 0 critical, 0 high.

License Management: Open Source Has Legal Implications

Not SOC2 related, but important when dealing with large customers and lawyers. Modern projects have hundreds or thousands of dependencies. Are you allowed to use and distribute them?

libraries.io lists:

• npm: 4.08M packages
• Maven: 588K packages
• PyPI: 500K packages
• Go: 485K packages
• Rubygems: 183K packages
• Cargo: 136K packages

Not all are free to use (Open source doesn't mean free). License types include:

• MIT License
• GNU General Public License (GPL)
• Apache License 2.0
• BSD Licenses (2-Clause, 3-Clause)
• Creative Commons Licenses
• GNU Lesser General Public License (LGPL)
• Mozilla Public License (MPL)
• Eclipse Public License (EPL)

Plus variations and proprietary licenses. Open Source Initiative lists over 80 approved licenses.

We use FOSSA to analyze dependencies recursively for license compliance. FOSSA integrates with GitHub and our CI/CD across Scala, Java, Rust, JavaScript, Python, Go, and more. This ensures we don't use dependencies whose licenses conflict with our business model or distribution policies (we ship on-premise software).

Financial institutions often request complete dependency and license lists. FOSSA generates shareable reports.

When to Start: Wait for Customer Demand

SOC2 becomes valuable at scale when customers require it. Wait for that demand. We're proud of this achievement and hope it gives users and partners confidence in our solutions.

Security requires ongoing effort. This audit is a checkpoint, not a finish line.