What's still annoying about SOC 2 in 2026

We just hit that milestone that every startup dreams of: we got back our SOC 2 Type II report from our auditor! Try not to be jealous. This covers the suitability of the design and operating effectiveness of our controls relevant to the Security and Confidentiality trust services criteria, throughout the period January 1 2026 to March 31 2026. If you’re a customer or prospect, get a copy from our trust center.

This isn’t my first SOC 2 rodeo. But it’s certainly different as the primary individual responsible for getting our ducks in a row. Although our CTO Eric handles engineering and production security, I cover everything else, from corporate security to policies to HR to operations. And I’m one of the lucky ones! For so many startups, the whole compliance team is one person (at least I have someone to talk to).

In the past several years, the best practices on SOC 2 haven’t really changed (see for example Latacora’s starting seven), but the tools certainly have. Compliance platforms are more expansive (and cheaper) than ever — leading to some, shall we say, questionable products. It’s not just the compliance platforms; the availability and quality of free security tooling, whether for vulnerability scanning, or SIEMs, is the best it’s ever been.

Given these advancements, what can I possibly share from our experience that might help you? What’s still annoying about getting a SOC 2 audit in 2026?

Access reviews are still manual

You need to regularly conduct access reviews (CC6.3) to ensure you didn’t miss any changes to users’ permissions when they moved roles, or you didn’t leave any permissions lying around when an employee left. In practice, what that means is pulling together a list of all of your apps, all the users in those apps (and the roles they have), and reviewing it piece by piece.

This is painful today not because that’s hard, but because it’s manual. You likely don’t have an authoritative list of all of the apps you use, and even if you did, they’re likely not all connected to your SSO provider, and even if they are, they don’t necessarily all enforce SSO and block other users from accessing it. So you do need to actually go into each of the apps to get this data, and dump it somewhere like a spreadsheet to centralize it so you can review it. What we did was create a template in Notion of all of our apps and their user pages (and admin pages, if separate), so we could just run the same process every time. Making this repeatable is what saves you.

The value we got from doing these reviews was variable, and really depended on what the vendor surfaced in terms of information about users in the app. First off, verifying user settings like MFA was incredibly confusing. Some apps have SSO (and MFA enforced via the IdP) but still show that the org doesn’t enforce MFA. Some apps like Google Workspace report that the user doesn’t have MFA enabled because they have been using a passkey. The only way we could disambiguate findings was by reviewing them app by app.

Conversely, having role information was quite helpful, and where we had the most ‘findings’. We found some roles were inconsistently granted in engineering apps that might not be used day-to-day, like Figma, Semgrep, and Sentry. These were generally for employees who had joined since the last review cycle: we hadn’t been consistent about what role they were being granted.

We didn’t find any red flags, and that’s not surprising at our size, but this review will only get more complex as we grow. And that’s part of why we’re working on this now at Oblique: to make access reviews easier for other orgs like us.

Evidence is still scattered across tools

A lot of SOC 2 is about scanning your infrastructure and code for vulnerabilities (CC7.1) and responding to those findings in a prompt manner — but maybe even more importantly, proving that you did. Our logs mostly route into RunReveal, but security alerts go to Slack, where we get notifications from RunReveal and Semgrep (Google Cloud alerts go to Security Command Center instead, since they'd bury everything else). The problem is that Slack was where alerts went to be seen, not fixed. Our actual work lives in Linear, so anything that didn't become a Linear ticket never got picked up or resolved.

Since there’s still an element of triage involved, we respond differently depending on the tool: logging alerts are immediately reviewed by an engineer, whereas vulnerability scanning alerts require regular checks to see if there’s anything worth fixing amidst the noise.

And since we have disjoint tools for scanning different parts of our stack — and they don’t feed findings into a central location — getting evidence of the work we’ve done to remediate these issues means we need to pull that information from several tools. Unlike access reviews, which are a snapshot of a point in time, logs have to provide historical context: they need to show not only when an issue was found but also when it was fixed. If you’re running a scan in your PR checks, it may not keep the historical logs you need. GitHub Actions keeps logs for 90 days by default, and you can raise that to 400 days, but you have to know to change this setting before you lose all your old logs. Even if you extend this, you might be fine for a 3 month audit period, but you certainly don’t want to discover this at the end of your 12 month audit period.

Unsurprisingly, the hard part of vulnerability management is the human process.

Some controls are still vestigial

Some parts of SOC 2 are from a bygone era, but it doesn’t mean you don’t need to follow them (you still do). One of the few things our auditor found we were missing evidence for is a device disposal tracker (CC6.5). We don’t have removable physical media, no one has left, and no laptop has been retired… so this has literally never happened. Even when we eventually do have to retire a laptop, it’s FileVault-encrypted with the org-wide key in Apple Business, so we can easily remotely wipe it. But don’t worry, we still created the tracker. (It’s a Linear issue label.)

Good security is still the best shortcut

Completing a SOC 2 audit, or any audit, is only proof that you can follow instructions for doing the minimum. But as a security company, it’s not enough for us to meet just the minimum requirements — we aim to be excellent at security. Luckily, investing in security also helps us simplify the work we need to do for our audit.

Our biggest audit win was not one we chose for compliance: adopting simple architecture. Boring infrastructure choices and deterministic tests make an environment easier to maintain — and easier to audit. We have a monorepo, use managed services to host our platform (Google Cloud Run and Cloud SQL), and use distroless container images as our base. And, we manage all of our Google Cloud infrastructure only as code in Terraform, and wherever possible where our other vendors allow it.

A lot of our security posture comes from engineering decisions we'd have made regardless of compliance:

• We use Go for our backend, which is a memory-safe language. We also use protocol buffers and gRPC for all of our APIs, which gives us strong typing between our frontend and backend. We can even ensure our SQL statements are free from user-controlled input.
• Checking in our configuration also allows us to write linters and tests against our production setup. We run PR-time checks to validate development flags can’t make their way to production.
• There's no shell into our production infrastructure. Cloud Run doesn't offer one, and we didn't build one because we don’t need it: everything in our production environment is managed via Terraform, and we have a test environment for testing new configs. For the audit, that means there's no privileged access to review: no bastion, no session logs, no break-glass SSH procedure to write down and test. And without write permissions, our engineers have limited access through alternative means like Cloud Console.
• Similarly, there’s no direct access to our production database. You can’t run ad hoc queries against prod. There's no direct DB credential or connection to lock down, audit, or worry about someone forgetting to revoke.

Completing an audit gives you the assurance that your controls are correctly implemented and work in practice. It forces you to think about your security holistically, and consider if there's an even better, more secure way to be doing the same task. But that warm fuzzy feeling can't keep us jaded security professionals going for long — we know an audit isn't proof you're secure, because you never really are. Still, we hope that sharing how we think about (and keep improving) our security is useful to you too. We'll keep at it.

If you need a copy of our SOC 2 report or want more information on our security controls, check out our trust center.